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Preface 


This velum.' contains the Track B (Work in Progress) proceedings of the l-jth 1„U nu.t.o.u.l ( <»„}, r< „c< on 
77, , ( ,rr »> Provnu, n, Hiqbt r Ordt r Loq.cs. TPHOTs 2002. held from t he 20t h to 2:ird of August 2002. and t he 
proceedings of the workshop on Formalising Continuous Math, , nat.es. I ( M 2002. held on the 10th of August 
2002 These events were collocated in Hampton. Virginia. ISA. A volume containing the I rack A papers of 
the conference has been published as Springer- Wring's Lecture Notes in Computer Science Xol.in.e 2110. 

The TI’llOLs International Conference serves as a venue for the presentation of work m theorem proving 
in higher-order logics, and related areas in deduction, formal specification, software and hardware verification, 
and other applications. Fourteen papers were submitted to Track B. which are included ... this volume. 
Authors of Track 15 papers gave short introductory talks that were followed by an open poster session. 

The FCM 2002 Workshop aimed to bring together researchers working on the formahsat ion of continuous 
mathematics in theorem proving systems with those needing such libraries for their applications. Over the 
last few years there has been great interest in formalising real and complex analysis. Many of the major 
higher order theorem proving systems now have a formalisation of the real numbers and various levels o 
real analysis support. Some work has also been done on formalising complex analysts including standard and 
non-standard analysis. This work is of interest in a number of application areas, such as fornial methods 
development for hardware and software application and computer supported mathematics. Ihe KM AV II. 
consisted of three papers, presented by their authors at the workshop venue, and one invited talk by John 
Harrison (Intel Corporation). Hie three papers were accepted for publication m this volume. 

All 17 papers in this volume were reviewed for relevance and quality of presentation by at least one person 
appointed by the program committee of each event. 
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II IIOLs 200 2 is organized l>y NASA Langley and l( ASt, in collaboration with Concordia l Diversity. 
1( M 2002 is organized by the I ni versity of Heading and K.'ASE in collaboration with Intel Corporation 
and INHIA. 

TPHOLs 2002 Organizing Committee 

Conference Chair: Victor A. Carreno (NASA Langley) 

Program Chair: Cesar A. Munoz (ICASE - NASA LaHC) 

Sofiene I aha r (Concordia (Diversity) 
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A Weakly- Typed Higher Order Logic 
with General Lambda Terms and Y Combinator 


James H. Andrews 1 

Department, of Computer Science 
University of Western Ontario 
London, Ontario, Canada N6A 5B7 
andrewsQcsd . uwo . ca 


Abstract. We define a higher order logic which lias only a weak notion of type, and which permits 
all terms of the untyped lambda calculus and allows the use of the Y combinator in writing recursive 
predicates. The consistency of the logic is maintained by a distinction between use and mention, as m 
Gilmore's logics. We give a consistent model theory and a proof system which is valid with respect to 
the model theory. We also give examples showing what formulas can and cannot, be used m the logic. 


1 Introduction 


The type system of a new higher order logic must be designed with care. Whenever we try to make the logic 
more expressive by permitting more well-typed terms, we risk making the logic inconsistent; for instance 
Church's higher order logic [Chu40] cannot consistently he extended to permit the rather modestly-extended 
terms of ML [Coq86]. However, greater expressivity allows us to make more concise, intuitive, and genera 
descriptions of the concepts we want to describe. 

Most higher order logics follow the pattern of Church’s original: one or more types are assigned to every 
term, and the type system is enforced with each rule of inference of the logic. Recently, however. Gilmore and 
others [Gil97,AK96] have been exploring higher order logics with only a weak notion of type, and no type 
enforcement across all terms. Consistency is maintained, not by types, but by a rigorous distinction between 
" USe ” and “mention” of predicate variables. In such logics, all the terms of the untyped lambda-calculus are 
permitted, and lambda-application can be used at the level of formulas as well. 

There is a price to be paid for the greater expressiveness in this area, of course: certain variables cannot 
he used in certain positions in axioms. We have reason to believe, however, that the restriction may not be 
important for many computer science applications. These logics give a very different view of higher or er 
logic which mav be useful in places where traditional higher order logics are not able to go. 

In this paper, we extend Gilmore’s ideas on the logic NaDSyL [Gil97] by defining a logic which further 
weakens the type svstem. allowing the use of the Y combinator. This weakening allows general recursive 
predicates to he defined and passed as parameters to other recursive predicates. We also present the proof 
system in the form of a conventional sequent calculus. 

Gilmore himself has recently moved in the direction of stronger types, producing a logic intermediate 
between XaDSvL and Church’s tvpe theory [Gil01,Gil02], The most relevant other related work that we 
are aware of is' that of Kamareddine, who defines a logic which gives a type to the Y combinator without 
permitting general lambda terms [Kam92], Our model theory is also similar m many ways to that of Chen. 
Kifer and Warren’s HiLog [CKW89]. 

In section 2, we give a syntax of terms and a semantics for the logic, and prove the semantics consistent. 
In section 3. we give a proof system, and prove it valid with respect to the semantics. In section 4. we 
illustrate the expressiveness of the logic, and the hounds on that expressiveness, by showing what forms 
of terms can and cannot be used in it; we also speculate about the consequent usefulness of the system in 
computer science and theorem-proving. In section 5, we give some conclusions. This is work m progress: we 
have not yet proven cut-elimination, although the proof system is designed to facilitate it; and we have not 
undertaken a thorough comparison of the recursive predicate constructs to those' in other higher order logics. 
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2 Syntax and Semantics 

Here we present the elementary syntax of t lie language, define simple term models for the logic, and prove 
some' consistency and substitutivity results. 

2.1 Elementary Syntax 

There are two sorts of variables, use and mention . We assume sets X u of use variables and X m of mention 
variables; the set X of variables is X u UX m . We assume a set V of predicate names and C of constants. The 
syntax of terms T in BNF is: 

T ::= .r | p \ c \ K \ (T T) \ A x.T 

where x is a variable: p is a predicate name; c is a constant; and A is oik 4 of the connectives and, not , 
and for all. We use x,y,z as metavariables standing for either use or mention variables, and XA\Z as 
metavariables standing for use variables in particular. We use p. q. r as metavariables standing for predicate 
names, and a.b.c as metavariables standing for constants. We use AL N as metavariables standing for 
arbitrary terms. All metavariables may be possibly primed or subscripted. 

As is standard, we write the term (...((M Ni)N 2 )...N n ) as (M A T j ... Ay). We write (and M N), 
{not A/), and (forall Ax. A /) as At He A r , and \/x.Al respectively. We define the notions of free variables 
and variable substitution in the usual way. We define a- and 3 -convertibility in the usual way, treating 
connectives as if they wen 4 constants. Two terms are off -equivalent if they an 1 convertible to the same term 
via an arbitrary number of a- or ^-conversion steps. 

The notions of “use term” and “mention term” are central to the semantics and proof theory. A mention 
term is a term with no free use variables. A use term is a use variable, a predicate name, or a use term 
applied to a mention term; in other words, a use term is one of the form (M N\ ... A r n ), where M is a use 
variable or a predicate name, and each A 7 ,; has no free use variables. The significance of use terms is that 
they are the only ones given an a priori assignment of truth value in the semantics. Examples of use terms 
include (p a b ), (A" a b ). (p q r), (p x y ). and (A r x p ), where z. y are mention variables. Examples of terms 
which are not use terms are (c a b), (x a b), and (p a A), where x is a mention variable. 

We denote the sets of use terms and mention terms by T u and T m . respectively, and the sets of ground 
use and mention terms by Q u and Q m , respectively. We denote the set of all terms by T. Terms which are 
neither use nor mention terms are still considered well-formed, and can appear in formal derivations. 

2.2 Model Theory 

To show consistency and to provide a reference point for the proof theory, we define simple term models. 
These models correspond to Gilmore’s models for NaDSyL [Gil97] in the same way that standard models 
correspond to nonstandard, Henkin-style models [Hen50]: they do not require the model to select denotations 
for use variables from a single given set. This relaxation simplifies the semantics. 

We use the symbols T.F to denote the truth values “true” and “false”, respectively. A model consists of 
a total function v and a countably infinite sequence v 0 ,vi,V 2 , ... of total functions, such that: 

- V : X tn Q m \ 

- If N and N' are a<3-equivalent mention terms, then v(N) = i'(X') : 

-v 0 :(X,.U V)^{T,F}\ 

- For every i > 0, v t : (X u UP)4 (G l m {T, F}); and 

- If N and N' are a/3-equivalent mention terms, then v,(M ){. . . , N , . . .)) = v, ( A/ ) ( . . . , jV' )). 

We now extend the function v to all mention terms. Let the extension vs of v w.r.t. a set S C X of 
variables be defined as follows: 

- vs(x) = x if x e S: 

- vs(x) = v(x) if x £ S but x € X m ; 

- i'slM) - M if M is a predicate name, constant, or connective: 

- v s (M N) = (v s (M) vs(N)); 

- vs(Xx.M) = \x.(v {Su{x}) (M)). 
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We then write v(M) for v^(M). Note that v(M) is undefined for free use variables, or indeed for any term 
containing a free use variable. 

Given a model (r, v 0 , G . ?'■> ). we also extend the functions v, to all use terms. We dehue 

Vi (M A’, ... Aj)(A : [, .... A’f) to be t» w+i ,(A/)(«(A T i v(Nj),N[, ... , A'/), for all t > 0. j > 1- "here 
M 6 (X u U V). A'*- € T,„ for till 1 < k < j, and N[. € G„, for all l<k<i. 

Given a use or mention variable x, a model M' = . . .) is an x -variant of another model 

Vf = (i.vi’o. t.’i ) if- for all mention variables y not identical to x, r'(y ) = v{y). and for all use variables 5 

not identical to x. rj(l’) = n,(I ) for all i >0. 

A signed term is a term preceded by a + or - sign, denoting truth or falsehood. We say that, a model 
M = (t\ no- Vi , . . .) entails a signed term ±M at stage, i, in symbols .Vf ]=, ±M ■ just in the following cases. 


- M |=o + (A/ AN AN . . . A’„) if M e (X u U V ), and 

v„(M)(v(Ni),v(N->) w(A ’„)) = T. 

- .VI |=o -(A/ A’i AN . . . N„) if M € (X u U V), and 
v„(M)(v(N \ ), t-’(A ? a), .... r(N „ )) = F. 

- m |=. + l +(MkN) if .Vf |=/ +M and M |=/ +A T . 

- ,V< (= i+ , -(MkN) if M (=i "A/ or M f=,- -A". 

- M h=i+t +(-A/) if M (=, -M. 

- M [=,+ 1 —(->M) if M (=i +A/. 

- M |=(+i +(Vx.A/) if for every j-variant M! of M, M' +-M ■ 

- M |=i+i — (Vx.Af) if for some r- variant W of .Vf, .Vf' (=, —M. 

- M N+i +((Ax.A/) A' i AN . A r n ) if .Vf \= { +(M[x := A'i] AN ... A'„). 

- M |=,+i —((Ax. A/) Aj AN . . . N n ) if M N ~(M[x := AN] AN . . . A'„). 


We say that .Vf entails ±M. in symbols .Vf |= ±M, if there is some i > 0 such that .Vf ]=,- ±M. 

As an example, consider a model M and a use variable X. Bv the definition of model, either .Vf (= -A' 
or M N +AN Therefore either .Vf |= -X or M f= ~(~>X), so .Vf (= -(Xk(~>X)), and thus .Vf \= 
+ (-,( A’&(->.V)))- Because this is true for every .Vf, it is also the case that .Vf ]= +VA(-'(A&(-'.Y))). Ex- 
pressing this formula more conventionally, .Vf |= +V.Y(A' => A'). 

An important point to note is the condition on the clause for - (A/AA ) above. ( A/.VA ) is entailed if 
either —M or —N is entailed; the other conjunct does not have to be assigned a truth value at all by the 
model. This is in contrast to Gilmore’s semantics for NaDSyL [Gil97]. in which the other conjunct had to be 
assigned a truth value. The relaxation of the restriction makes the Y-combinator more useful. We can never 
entirely eliminate the Y-combinator from a typical recursive predicate term by beta-conversion, and thus can 
never convert a term with a Y-combinator into one in which all atomic terms are use terms. However, the 
-(MkN) clause allows, for instance, (MkN) to be false when M is false, regardless of whether N contains 
an irreducible term such as a \ -conibinator. 


2.3 Consistency and Substitutivity 

Here we prove that, it is impossible for a term to be both true and false in a model. We also prove some 
results concerning the substitution of mention terms for mention variables and use terms for use variables. 
These substitutivity results will be useful in later proving soundness of the proof system. 

Theorem 1. For every model M arid every term M, it is not the case, that both M |= +M and .Vf |= - A/. 

Proof. If .Vf j= ±A/, then for some i > 0, .Vf \= t ±M. The proof is by induction on i. If i = 0. then M 
must be a use term, and bv definition the model must assign one unique truth value to the term. Otherwise* 
(i > 0), cases are on the form of Si. If M is (A/,AA/,). then .Vf (=j +M iff .Vf N-i +Mi M N-i +^->- 
But in this case, by the IH, we can have neither .Vf i -Afj nor .Vf [=,- 1 -M 2 , and therefore we cannot 
have .Vf |=, -A/. Conversely, if .Vf j=, : -A/, then either .Vf |=,_i -M t or .Vf |=j_i -A/ 2 . But m neither case 
can we have both M |=,-l +A/i a nd M |=,_! +A/ 2 , and therefore we cannot have M ]=, +M. The other 

cases follow the same straightforward reasoning. ^ 

We define the complexity of a term M, in symbols k ( A / ) , as follows. k(Xx.M) = k(M ) + 1, k(i I i ) — 
max(k(M), k-(N)) + 1: and k(M ) = 0 when M is a variable, constant, predicate name or connective. 
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Theorem 2. Let x be a mention variable and M a mention term . For every mention term N and every 
model M such that v(x) = v(M), v(N) = ?j(A r [x := A/]). 

Proof. By induction on the complexity of N. Cases are straightforward. □ 

Theorem 3. Let x be a mention variable and M a mention term. For every i > 0, every term N and every 
model M such that v(x) = v(M) f M Mi ±A T iff M M> ±N[x A/]. 

Proof. By induction on /. 

If i = 0, then A is a use term, of the form (A : o Ay A ' 2 . . . Ay,). where Ao is a use variable 4 or predicate 4 
name. By the definition of (=, M Mo +(AT 0 Ay A 2 . . . N n ) iff v „ (N 0 )(v{N x ),v(N 2 ), . . . , v(N n )) = T. Because 
of the last theorem, this is true iff v n (N 0 )(v(N x [x := M]),v(N 2 [x := A/]), . . . ,?;(Ay,[x := M])) = T. (x does 
not appear fret 4 in Ao, so A r 0 [x := A/] is A r 0 .) By the definition of (= again, the previous statement is true iff 
M (=0 +(A T 0 N { [x := A/j N 2 [x := M] ... Ay,[.r := A/]); that is, iff M Mo + (Ao A r i N> ... A T „)[x := A/]. 
The subcase with — instead of + is similar. 

If / > 0, then one of the other cases of the definition of the Mi relation holds. The cases of the propositional 
connectives are straightforward. 

If A r is Vy.N f , then we assume without loss of generality that y is not x and that y does not appear in 
A/. M Mi +(V;jy.A r/ ) iff for every y -variant M! of AA , AA 1 M*-i A-N'. By the induction hypothesis, this is 
true iff for every y- variant M f of M , M' Mi-i +A r '[x := A/]. Because of the assumption, this is true iff 
M Mi +(V*/. N'[x := A/]); that is, iff A4 Mi + (V.t/.A r ')[x := A/]. The subcase with — instead of + is similar. 

If A is ((Aj/.Ao) Ay A 2 . . . A n ), then AA M? +A r iff A4 Mi — 1 +(AoM := Ay] . . . Ay,). By the induction 
hypothesis, this is true iff M Mi-i +((A'o [y := Ay])[x := M] N 2 [x := M] ... N n [x := A/]). We assume 
again that y is not x arid that y does not. appear in M. Therefore because of the properties of substitution, 
this is true iff M Mi-i +((Ao[x := M])[y := (A r i [x := A/])] N 2 [x := M] . . . N n [x := A/]). By the definition 
of M, this is true iff M Mi +((Xy<N 0 [x := A/j) A T i[x := A/] A T 2 [x := A/] ... Ay,[x := A/]); that is, iff 

M Mi A-((Xy.No) Ay A r 2 . . . Ay,)[x := A/]. The subcase with — instead of + is similar. □ 

Theorem 4. Let X be a use variable and M a use term. For every i > 0. every term A r and every model 

M such that Vj(X) — Vj(M) for every j > 0, M Mi ±A r iff M M ±N[X M]. 

Proof. Similar to the proof of the last theorem, except for the base case of the induction. 

If 1 = 0, then A is a use term, of the form (A r o Ay N 2 . . . X n ) , where A r o is a use variable or predicate 
name and the Ays have no free use variables. If A r 0 is not a use variable, or is a use variable different from 
V, then A r [A := M] is N , and the result follows immediately. 

If A r 0 is A", then A r [A := M] is (M Ay N 2 . . . AT,,). By the definition of M? XA Mo +(X N x N 2 . . . N n ) iff 
v n (A )(?;(Ay ), i/(A r 2 ). . ■ . , c(Ay,))) = T. By assumption, it is also the case that ?y,(A/)(?;(Ay ), v(N 2 ), . . . , v{N n ))) 
T. If M is a use variable or predicate, then the result follows immediately. Otherwise, M is (A/ 0 M\ . . . A/ m ). 
By the definition of v n (M), 

v n (M)(v(N { ), v(N 2 ), . . - y v(N n ))) = T = v m +?j(A/o)(v(A/i ), .... v(M m ), ?;(Ay ),..., u(Ay, ))) 

Therefore M Mo +(A/o M \ ... M m Ay . . . N n ). Now it is also the case that 

(Mo Mi ■ • • M m N\ . . . Ay,) = ((A/ 0 M x . . . M m ) N x . . . Ay,) - (A/ Ay . . . N n ) = (X[A := M] Ay ... Ay,) 

Since A does not appear free in the Ays, this last term is equivalent to (X Ay ... Ay) [A := A/], or 
A [A := A/]. Therefore AA Mo +N[X := A/], as desired. The subcase with — instead of + is similar. □ 

3 Proof Theory 

Here we present a proof system for the logic, in the form of a classical sequent calculus similar to Gentzen’s 
LK. We give notational preliminaries in section 3.1. In section 3.2, we prove soundness of the proof system 
with respect to the model theory; in section 3.3, we briefly discuss the prospects for cut elimination. 
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where M, M' are use terms and M =,» < ? A/' 


Thin/1: 


n-d 
r. 3/ h i 

Thin/r: 

fhd 

rh j, 3/ 

Con/1: 


r, 3/. 3/ 1- a 
r. 3/ 1- _i 

Con/r: 

n-i a/, 3 / 
r t- a, m 

k/ 1 : 


r. 3/. -V k a 
r. a/&a' h- j 

k/r : 

r\- a.m r \- a. A' 
n-A. A /A: A' 

-/l: 


rn 3/ 
r. — > a/ h a 

'/ r: 

r, a/ 1- a 

/• h _ 1 , — ■ A/ 

V/i: 


r, A/[x := A'] H J 
ryx.M f a 

V/r: 

r 1- A. A/[x := 37 ] 
r 1 - _i.Vx.AZ 


where x is a use 
(mention) term 

(mention) variable, and A 

is a use 

where x is a use (mention) variable, and y 
(mention) variable not appearing free in /. 


r. (Ml 

r := Ni\ A 2 • * ♦ A' n ) F -A 

0 /r: 

f I- ( 3/[x := A r i] N-i . . • An ). A 

0 / 1 : 

C ((Aar. A/) A r i JV 2 . . . An) F -A 

r I- ((Ax. M) N\ N> . . . Nn ) , -A 


Cut: 


r a. a/ a/, r h j 

rhj 


Fig. 1. Proof rules for proof system G. 
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3.1 Notation 

A sequent is an ordered pair of finite multisets of terms, written in the form fh J. We will use F and A 
as metavariable standing for multisets of terms; the notation F,_i will mean F l±i J, and F, M will mean 

Fl+J {A/}, where 1±J is multiset union. We present the proof system in the form of Gentzen-stvle proof rules 
for sequents in Figure 1. 

In Gilmore's original presentation [Gil97], he defines a semi-decidable set of formulas: the restriction on 
the V/l rule then essentially ensures that the term in the upper sequent must he a formula. The condition 
here is weaker, lmt simplifies the presentation. 

Since the rules define a complete set of classical connectives, it is clear that we can introduce all the 
other classical connectives, such as V (disjunction). (implication) and 3 (existential quantifier). We will 
use these connectives in the sequel without further comment. 


3.2 Soundness 

We say that a sequent F h J is valid in a model .Vf if either there is an M G F such that M |= —M. or 
then- is an N G A such that M |= +N. We say that a sequent F b J is valid if it is valid in all models. ’ 

Theorem 5. Every provable sequent is valid. 


Proof. By structural induction on the derivation. Cases are on the last rule applied. In the following, we 
write M ^ -F to mean that for all M £ /\ M -A/. 

- Reflexive «nt ailment: let the sequent he T, M h A, M‘ such that M = a(3 M' and M is a use term. 
Assume that M —T arid M ^ —M. But since Af is a use term, either M —A/ or M 1= +A/; 
hence, M ^ +A/. By the definition of model, M |= + M* as well. 

- Thin/1: let the lower sequent be F , M h A. Assume that M -F and M ^ -A/. Then by the induction 
hypothesis (IH) on the upper sequent, Ad |= for some N £ A. 

Thin/r: Assume that M ^ -F. Then by the IH on the upper sequent, M |= +A T for some N £ A. 

- Con/1, Con/r: straightforward. ^ 

(k/l: let the lower sequent be T, MkN F A. Assume that M ^ -F and M ^ -(M&N). Then neither 

M |= — M nor M |= -N, because otherwise M f= -(A/ &.N). Thus, by the IH on the upper sequent for 
some N' G A, M f= +A 7 '. 

- fc/r: let the lower sequent he F b A, MkN. Assume that .Vf ^ -F. There are two subcases, (a) If 
M \= +N' for some N' G A. then the result follows immediately, (b) Otherwise, bv the IH on the upper 
left sequent, it must be the case that M |= +M; and by the IH on the upper right sequent, it must be 
the case that M |= +A r . Thus, .Vf (= +(A/&A r ). 

->/l: let the lower sequent be t,->M b A. Assume that .Vf ^ -F and .Vf ^ -(->Af). Then M ^ +M. 

because otherwise .Vf |= — (->A/). Therefore by the IH on the upper sequent, there must be some N G A 
such that .Vf )= +A r . 

f/r: ,ct the lower sequent be F b Assume that M ^ -F. There are two subcases, (a) If there 

is some A G A such that M |= +A, then the result follows immediately, (b) Otherwise, by the IH on 
the upper sequent, Ai |= —A/; therefore .Vf + (-iA/). 

- V/l: let. the lower sequent be F, Vx.M b A. Assume without loss of generality that x does not appear free 
in FA, Ah Assume that. M £ -F and M £ -(Vx.M). Let M = (v, u 0 , v,. . . .). We know that for anv 
x- variant .Vf of .Vf. .Vf' ^ —M, because otherwise M f= -(Vx.M). There are two subcases, (a) If x is 
a mention variable, this means in particular that .Vf' ^ -M where .Vf' = (v' .v' 0 . v[. . . .) is an ar-variant 
of .Vf such that v'(x) is the same as w'(JV). Therefore by Theorem 3. M' £ -M[x := N]. and by the 
induction hypothesis, there must be some N' € A such that .Vf' (= +N', Since x does not appear free 
in A, it must be the case that M )= +N' as well, (b) Similarly, if x is a use variable, this means that 
.Vf -M where M' = (v‘ ,v' 0 ,v[, . . .) is such that vj(x) is the same as v'(A 7 ) for all i > 0. The proof 
proceeds similarly, using Theorem 4. 

- V/r: let the lower sequent be F b A.Vx.M. Assume that, M £ -F. There are two subcases, (a) If there 
is some A G J such that .Vf (= +A r , then the result follows immediately, (b) Otherwise, by the IH on 
the upper sequent, .Vf |= +M[x := y]. But then for the x-variant .Vf' of .Vf in which v(x) = v(y) (if x 
is a mention variable), or u,(x) = c, (y ) for all i > 0 (if x is a use variable), we have that .Vf' 1= +M 
Therefore .Vf |= +(Vx. A/). 
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I .V = *’)))) h (- V (A-rFF = :r )R> 

R.V (AxRx = a')))) => (.V (Ax(-.(x = x)))) 
Fv a~.((.V (Ax(-h(x = x)))) =» (-Y (A x(-.(x = -?))))) 
T ((Ax(-.(x = J))) = (AxRx = J)))) 
->((Ax(--(x = x))) = (Ax(-(x = x)))) F 
((A.r(~'(.r -- a:))) (Aj(--(j = x)))) F 
h -.((AxHx = x ))) (Ax(-<(x = -r)))) 

I- (Ax(--(x x))) (Ax(-i(x = x))) 


Fig. 2. The proof that the empty set is in the Russell set. 


B/r: Straightforward applications of the induction hypothesis. 

Cut: let the lower sequent he F h J. and the cut term be M. Assume that M f -T. There are two 
subcases, (a) If their is some N € A such that M N +N, then the result follows innn(diat(l.v(b) 
Otherwise, from the IH on the upper left sequent, M |= +M; hence M ^ -M ■ Therefore In the on 
th(> upper right sequent, there must, be some N £ A such that M (= +^ ■ 


3.3 Cut Elimination 

Because the proof system is valid with respect to the model theory, it inherits the model theory's consistency. 
Despite this, we would also like to prove cut-elimination. This would demonstrate that the proof system is 
compositional in a useful way. We have not completed the proof, but the proof system has been d^,gncjd 
to allow it to proceed. For instance, any use term should be able to be substituted for a free use variable 
in a valid derivation, facilitating the important subcase of cut-elimination where the cut term is a universal 
quantification on a use variable. 


4 Expressivity 

Here we illustrate the expressivity of the logic, and the limits of that expressivity. In Section 4.1 we define 
and prove theorems about the Russell set. In Section 4.2, we show that the Y combmator can be defined and 
used In Section 4.3, we show that Gilmore’s operators for constructing recursive sets can still be used and 
still have the effect of giving us proofs by induction without having to define an explicit induction rule. In 
Section 4.4, we show formulas that cannot be used in a truly useful way, and speculate on what consequences 
this has for the logic. Finally, in Section 4.5, we discuss “nonsense formulas’ that can arise given the syntax 
and proof theory of the logic, and propose a familiar solution. . , , « 

In this discussion, we will take the notation M = N as shorthand for Frege s identity of indiscernables 

property, VA\((A r M) => (A A ) ) . 


4.1 The Russell Set 

The Russell set R can be expressed as Ax(->(x x)), and stands as usual for the set of all sets which an not 
members of themselves. Given that the empty set E A*H* = x)) is not a member of itself, but the set 

of all terms A = f Ax(x = x) is a member of itself, we should be able to prove both (R E) and ->(R A). ^ 
Figures 2 and 3 show these derivations. (In all derivations in this paper, we occasionally insert "steps in 
which we simplv expand definitions.) These derivations demonstrate that the logic of this paper retains tlie 
expressiveness of Gilmore’s NaDSyL [Gil97], which can also express these derivations. It also demonstrates 
that, the logic is in this particular way more expressive than Church s [Chu40] and Ramareddme s [Ram ], 
in which the Russell set cannot be assigned a type and thus cannot appear m derivations. 

The Russell set is not particularly useful by itself, but its presence is an indication of the difference 

between Gilmore logics and traditional type theories. 
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(X (\x(;r = x))) h (X (A x(x = x))) 
h ((.V (Ax(x = x))) => (A (Aj(.r = j)))) 
h VA.((.V ( Ax(x = x))) =» (.V (Xxjx = x)))) 
I- ((Ax(x = x)) = (Ax(x = x))) 

I- ((Ax(x = x)) ( Ax(x = x))) 

~'((Ax(x = x)) (Ax(x = x))) h 
(( Aj?(— »( ic x))) (Ax(x = 3-))) h 
I- — -((A x(->(x x))) (Ax(.r = x ))) 


Fig. 3. The proof that the set of all terms is not in the Russell set. 

I- (., 0) = (* 0) h ((Y N) 0) 
h ((., 0) = (» 0)&((Y N) 0))) 

P 3y((» 0) = ( a y)fe((Y Nf»j)) 

I- (* 0) = 0, 3y((s 0) = (,s y)fc(( Y N) y))j 
I- ((,s 0) = 0 y 3t/((.s (1) = (,s y)fc((Y N) ?/))) 
h ((Ax.(x = 0 V 3y(x = (s j,)fc((Y N) */)))) (,s ())) 


Fig. 4. Part of tin* proof that (s 0) is an integer 


4.2 The Y Combinator 

Let V(w) be Xv.(w (v v)). Then Curry’s Y combinator can be defined as Y = f A w.(V(w) V(w>)). We define 
the set of integers as consisting of 0 and all terms of the form ( s n), where s and 0 are here assumed to be 

constants and n is an integer. If we define N = f \u.\x.(x = 0 V 3 y{x = (* j/)&( u y))). then (Y N) expresses 
the set of integers. 

Applying beta-reduction and definition expansion/contraction to this term yields the following. 

(Y N) = (Au\(V(te) V(iti))) N 
= (V(N) V(N)) 

= (Av.(N (v v))) V (N)) 

= (N (V(N) V(N))) 

= (N (Y N)) 

= (Au.Ax.(* = 0 V 3 y(x = (s y)k(u y))) (Y N)) 

= Xx -( x = 0V 3y(x = (s y)k(( Y N) y))) 

Figure 4 shows part of a derivation of the term ((Y N) (,s 0)); this may be read as the statement that 
the term (s 0) is an integer. The omitted parts of the derivation, at the top, are straightforward given this 
derivation and the previous derivations. This derivation demonstrates that the Y combinator can be used 
in this logic, as in Kamareddine’s [Kam92]. The Y combinator is disallowed in Church’s T system [Chu40] 
and in Gilmore's ITT [GilOl ,Gil02] because it cannot be assigned a type; it is disallowed in NaDSyL [Gil97l 
because no term containing it could be considered a -‘formula”. 

Despite the presence of the Y combinator and implication, Curry’s paradox [HS86] is avoided because 
the sequent M h M is not an axiom if M is an application of a lambda-abstraction. An attempt to prove 
Curry s paradoxical formula leads only to an infinite regress. 


4.3 Gilmore’s Operators 

Gilmore [Gil97] defines a kind of “intersection" operator which can be used to construct recursively-defined 
sets. The intersection operator L is XX.Xx.W((X Y) => (Y x))- given a property M and a term N, the 
term (L M A ) will be true if N is a member of all sets with the property M. Let Z be the property of 
being a zero-successor set, i.e. the property of a set containing 0 and all of its successors. Z can be defined 

as A Z.((Z 0)&Vy((Z y) => (Z (s j /)))). Then the term N' d = (L Z) expresses the property that an individual 
is in every zero-successor set; that is, N' stands for the set of natural numbers. 
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(M ;/) b (M (.s ?y)) 

h {(&! g) =» (M (* //))) 

F (M 0) I- Vy((A/ ?/) =» (M (.s . 1 /))) 
b ((A/ 0)fcVi;((A/ y) =» (A/ (s ?/)))) 

(A/ x) b (M x) b (AJ x),((A/ 9)fcVi/((A/ */) => (A/ (s y)))) 
(((A/ 0)fcVy((A/ ?/) => (A/ (,s y)))) => (M *)) b (M g) ~~ 
VV((( V 0)fcVy((V y) => (V (« ?;)))) => (T g)) h W x) 
(N' x) b (A/ x) 
b (N' x) =» (A/ x) 
b Vx((N' x) => (M x)) 


Fig. 5. Part of a proof that the use term M expresses a property held by all integers. 


Applying equivalences and definition expansions yields the following equivalent definition for N : 

(L Z) = ((AA'.A ,r.VY'((A' V) =k (V x))) Z) 

= Ax.VY((Z Y) =*• (Y x)) 

= Ax.VV(((A Z.((Z 0 )&V»((Z iy) => (Z (s »))))) 1') =► (V x))) 

= Ax.VY(((Y 0)&Vy((Y y) => (5' («?;)))) => x)) . _ , , „ 

The significance of this expression, as in Gilmore’s previous logics, is that a proof of a property of all 
natural numbers automatically consists of a proof by induction. Figure 5 shows a generalized proof of the 
term schema Vx((N' x) => (M x)), that is “property M holds of all integers", for any given use term AI. 
The derivation follows the general pattern of reducing the problem of proving the term to the problem of 
proving (M 0) and Vj/((Af y) => (M (s ?/)))• 

This latter property may Vie useful in automated theorem proving, since it allows us to prove properties 
concerning recursively defined s<Ts by induction, without explicitly requiring induction rules or tactics. 
Naturally, other tactics may be required, and it remains to be seen whether they are easier or harder to use. 


4.4 Disallowed Formulas 

Terms such as (A' Y), where A' and Y are both free use variables, cannot appear in axioms. As a consequence 
of this they are not reallv useful in any derivation except when one or both are bound by a lambda, although 
they are not excluded by any type restriction. The logic of this paper shares this property with Gilmore s 

two recent logics [Gil97,Gil01] . , . , 

In contrast, of course, in most higher order logics from Church’s [Chu40] to Kamareddine s [Kam92], a 
term of the form (A Y) is allowed as long as the types are appropriate. This leads to many natural uses 
of predicate variables applied to others, such as that of assigning a value to a predicate variable and later 
applying it to another predicate. The fact that applying a variable to another comes so naturally for us may 
lead us to believe that we cannot do without it. 

However, note that non-recursive and recursive properties of general predicates can still be denned 
in the logic of this paper. The property that a predicate is transitive, for instance, can be defined as 
A V (VxVyVz {(X x y)k{ X y z) => (X x 2 ))). This term can be applied to any predicate or use variable, 
or indeed to any term, including one using the Y combinator. The transitive closure operator on a binary 
relation can be defined using the Y combinator: if T is XZXX Xx\y.((X x y) V 3z((A x z)k(Z A - ?/)))* 
then ((Y T) M) is the transitive closure of a term M. Again, M can he a predicate name, a use variable, oi 
another term defined using the Y combinator. Applying ((Y T) M) to two terms will result in a term which 

can have a derivation of the same general form as that in Figure 4. 

This property gives us reason to believe that the logic of this paper can still be useful in working with 
higher order recursive definitions. It will always be impossible to use terms such as VA'Vi ((A' 5 )=►...) as 
formulas, but such formulas may not be needed for some applications. 

Moreover, note that a use variable can be applied to a particular predicate, such as in the term (A p). 
This allows us to, for instance, state assumptions about the application of p to other terms on the left-hand 
side of a sequent , and assert properties of p itself on the right-hand side. We simply cannot generalize fiom 
a property about a given predicate p to a property of all use terms. 
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4.5 Nonsense Formulas 

We have so far in this paper restricted our attention to formulas that “make sense" in an intuitive way. 
However, readers have probably noticed that there are many terms which can be written and can appear 
in formulas but don’t make sense, such as ( and and), (Y x), and Vx.(c). There are also many terms which 
make sense but cannot be construed as formulas, such as Axjx = ./•); if we try to build a derivation of an 
ill-constructed formula, we may be faced with such a term in a formula position. 

The natural way to address this problem is a familiar one: to impose a type system on the terms of 

the logic. Note, however, that since types are not needed for consistency, we can choose our type system 

based on considerations ol expressivity. For instance, the Y combinator can be given a type in type systems 
with fixpoint types and universal types, such as those described bv Cardelli [Car96]; such type systems 
are normally inaccessible to us in higher order logics because they allow such problematic terms. Using 
Gilmore-style logics, we can choose our type system to include such terms if we so desire. 

The weak type system of use and mention variables used in the logic in this paper does not seem to 

interact with a more conventional type system except in one respect. Let us assume that o is the type of 

propositions. It does not seem to make sense to allow constants and mention variables to have a type ending 
in o (i.e., a type of the form (,4j — > .4_> — > .4 ;j —>•••—► <>)). since they can never appear as the head term of 
a formula in an axiom anyway. Conversely, it does not. seem to make sense to allow predicate names and use 
variables to have any type not ending in a. 


5 Conclusions and Future Work 

We have shown another facet, of the complex jewel of consistent higher-order logics, one close to that shown 
by Gilmore in his earlier work. Whether the logic of this paper turns out to be useful remains to be seen, but 
we believe that its existence should be interesting to the community of researchers working with higher order 
logic. Future work includes a proof of cut-elimination and more in-depth study of the nature of recursive 
and higher order definitions in comparison to previous logics. 
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Abstract. We present the design of a formal integrated design environment. The long-term goal of 
this effort is to allow seamless interaction between software production tools and formal design and 
analysis tools, especially between compilers and higher-order theorem provers. The work in this report 
is the initial design and architecture for integration of 1) the* MetaPRL logical framework, 2) a multi- 
language compiler we call Mojave, and 3) a generic extensible parser we call Phobos. The integration 
is currently performed at the level of the Mojave functional intermediate representation, allowing the 
use of the theorem prover for program analysis, transformation, and optimization. 


1 Introduction 


W e are developing formal integrated design environments (FIDEs) where formal and informal tools are used 
in a symbiotic relationship. That is, interactions between the formal and informal parts of the FIDE art 1 
bidirectional and interdependent. 

Most, if not all, existing formal design environments do not allow bidirectional interactions, especially 
between the theorem prover and the compiler. Yet, the system would clearly benefit from closer interaction. 
For example, the compiler might be able to use the theorem prover for optimization, proof validation, or 
program transformation. The theorem prover would benefit from the ability to formalize its own code, 
especially tactics. 

The larger need is for effective formal programming languages. By “effective” we mean that the languages 
should be general enough and efficient enough to use in software production. By “formal” we mean that 
programs can be both specified and verified. The compiler is responsible for efficiency, the prover for formality. 
In order to achieve both properties simultaneously, we argue that the theorem prover and compiler must 
interact closely (or, equivalently, one must be folded into the other). 

In this paper, we describe our initial work integrating the MetaPRL logical framework with our Mojave 
multi-language compiler. There are several parts that are needed for integration: 1) the compiler and theorem 
prover must share a common language, 2) the compiler must allow for an extended program syntax that 
includes specification, and 3) the compiler and prover must also agree on a common program semantics, 
especially operational semantics. We present the following results: 

— an architecture and implementation for the MetaPRL/Mojave formal design environment, 

- a shared typed intermediate language, with semantics defined in the MetaPRL implementation of the 

NuPRL type theory, 

- an extensible front-end, called Phobos. that uses the MetaPRL rewriting system for extending and 

defining programming languages, 

— and examples of using the theorem prover for optimization. 

Section 2 describes related work. Section 3 describes the MetaPRL, Mojave, arid Phobos systems indi- 
vidually, and Section 4 presents the combined architecture. We give example applications in Section 5, and 
finish with a summary of future work. 


* This work was supported bv the ONR, grant N00014-01- 1-0765: DARPA, grant F33615-98-C3613: and AFOSR 
grant F49620-01-1-0361. 
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2 Related Work 

This work initially started with the development of the MetaPRL system [G 8], MetaPRL is a logical frame- 
work. designed to allow relations between logics. MetaPRL is also designed as a “Logical ^ograimmng 
Environment'’ (LPE) where programs, type systems, proofs, and specifications can all be dchmi am 

tU °One of die problems with the MetaPRL design is that it is a layered architecture. The theorem provor 
is layered above the OCaml compiler [16], and the connection is unidirectional. Any task (such as parsing, 
type' inference, and scoping) that is assigned to the compiler is not. available to the formal system, hindering 
effective formal software development. 

In another related effort, we used the NuPRL system to optimize communication protocols foi tin En- 
semble group communication system [12.11]. Again, this project separated the prover from the compiler. 
To optimize a protocol, a parser would convert the protocol and requirements into an expression m the 
\uPRL type theory; the prover would apply optimization tactics to generate a ■‘fast-path: and the icsult 

would be printed as a ML file to be compiled by the OCaml compiler. While successful, tins was awkward 
Furthermore, optimization strategies were defined in NuPRL, not as part of the program code, making it 
difficult to synchronize the formal system with new Ensemble code releases. The architecture we propose m 
this paper is an effort to design a system where formal properties are “first-class program properties, and 

the prover/ compiler interaction is seamless. . . . i 

in other related areas. Sannella and Tarlecki's Extended ML [9. 10] allows mixing of program implemen- 
tation and format specification for SML programs. The ACL2 system [3] allows extensive mixing of formal 
specification and Common Lisp programs. Nearly all other formal systems including systems like HOL o] 
PVS [4] and Isabelle [14], allow extensive reasoning about programs, but the pi over is not coup e wi 1 
compiler as we are proposing in this paper. 


3 Architectural Components 


There are three major parts to our architecture. The MetaPRL system provides reasoning, the Mojave 
system provides compilation, and the Phobos system provides generic, extensible parsing. The overall system 
architecture is shown in Figure 1. 



Machine code MetsPRL 


Fig. 1. System architecture: Path (i) corresponds to a traditional compilation path augmented by the theorem prover 
Path (ii) uses the dynamically extensible front end. 
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Fig. 2. MetaPRL system architecture 


3.1 The MetaPRL system 

MetaPRL is a logical framework , designed along the same architectural principles as the NuPRL system. 
The system architecture is shown in Figure 2. The refiner contains three parts: 1) a term module, which 
defines the system syntax, 2) a logic engine, for theorem proving, and 3) a bookeeping module to manage 
and validate proofs, and perform program extraction for constructive proofs. 

The meta-language defines the language of tactics and conversionals (rewriting tactics), which are used 
to define decision procedures and proof heuristics. The entire MetaPRL system is written in OCaml, and 
OCaml is used as the language for tactics and conversionals. 

The topmost layer in MetaPRL is the definition of theories arid logics. A theory is defined by 1) its 
syntax (defined using terms), 2) its proof and rewriting rules, 3) its tactics and conversionals, 4) its theorems, 
expressed as derived inference and rewriting rules, and 5) other utilities for display and pretty-printing. 


Judgments Inference rules are often, though not always, described in a sequent logic. For example, the 
following inference rule would describe the implies introduction rule in a propositional logic. 


rule imp-intro H : 

[main] (H,v: A h B) — > 

[wf] (H h A type) — > 

H h A =» B 

In this rule, the variables .4, B , are met a- variables that represent arbitrary terms and H represents a 
context. The sequents labeled “main” and “wf” are the premises of the rule; “main” is the main premise, 
and “wf” is a well-formedness requirement. The — > operator is the meta-implication that MetaPRL uses to 
represent inference rules. The declaration of the imp_ intro rule defines a tactic, called imp_int.ro that, can 
be used to “refine 1 any goal of the form H \- A => B into two subgoals. From here, it is straightforward, for 
example, to define a derived rule (a theorem) that would apply to sequents of the form H h .4 => B => C. 
The proof would use the imp_intro rule twice, and there would be four premises. 

Rewriting judgments are defined in a similar way. The rule for beta- reduction in the untyped lambda 
calculus would be expressed using the following rule. 

rewrite beta : apply {lambda {v.e\ [u]); e 2 } 4 — > ei[e 2 ] 

This declaration defines a conversion called beta that can be applied within a proof to any redex, 
performing the substitution. Note that the statement of the rewrite uses second-order substitution [1, 13]. 
The pattern e.\ [v] represents a term in which the variable v is allowed to be free, and the term cj [e 2 ] represents 
e i with 62 substituted for 
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Syntax, and terms All logical terms, including goals and subgoals, arc expressed m the language of tarns. 
The general syntax of all terms has three parts. Each term has 1) an operator-name (like “sum ). winch is 
a unique name indicating the logic and component of a term: 2) a list of parameters representing constant 
values; and 3) a list of subt.erms with possible variable bindings. We use the following syntax to desui )e 
t onus, based on the NuPRL definition [2]: 


opname \p\ : • • • : p n ] {^l-f 1 * ‘ < v m-tm 

oi>rratnr name parameters subterms 


A few examples art 1 shown at the right. Variables an 1 trims 
with a string parameter for their name; numbers have an integer 
parameter. The lambda term contains a binding occurrence: the 
variable x is bound in the subterm b. 


3.2 The Mojave compiler 


Displayed form 

Term 

1 

number [1] { } 

X.T.I) 

lambda [] {x. b} 

/(«) 

apply []{f; a} 

V 

variable [ M v M ] { } 

X + jj 

sum [] { x ; y} 


The Mojave multi-language compiler, shown in the left half of Figure 1. is made up of three major parts 
The front-ends are responsible for compiling code to the functional intermediate representation (UK), and 
the back-end is responsible for generating machine code from FIR. FIR type inference and optimizations 
form the middle stage of the compiler. The FIR is the primary concern for this paper: it is the language we 
arc using for interaction with MetaPRL. 


Functional Intermediate Representation The FIR is designed to be a minimal, but general-purpose 
typed intermediate language. The FIR has higher-order functions, polymorphism, and object types. We will 
describe it in two parts, first the type system, and then the programs. 


The FIR type system The FIR type system is based on the polymorphic lambda calculus. The type system 
is shown in Figure 3. There are the normal scalars, including native integers with various bit precisions 

(Z H Z 64 ) as well as “boxed" integers, enumerations {0...i} whose values range from 0 to / - 1, ant 

floating-point numbers. Enumerations are used to code several base types: the empty type Void is {0 ... 0} , 

Unit is {0 ... 1}, etc. rr . 

Functions have multiple arguments. The type (t, , . . . . t n ) -> t is the space of functions taking arguments 

with types f and returning a value of type t. 

Tuples (t i t n ) are collections of elements having potentially different type. The t array represen s 

variable- sized ' arrays of elements all having type t. The data type is used specifically for C: it represents a 
variable-sized data area containing elements of any type. Values of data type are not statically type-checked, 
it is not a tvpe error to store an integer in a data area, and immediately fetch a value from the same location 
with some other type, but the runtime will raise an exception if the operation is unsafe. 

Types are always defined relative to a context T that contains type definitions and scope information for 
polymorphic variables. The union type .la,, . . . ,a„.ti +■■■ + t m is a polymorphic disjoint union of tuples 
<i t m A value with a disjoint union type is a tagged tuple of type U with tag i for some i € {1. .... n}. 
If v defines a union type /la, o „. h + •■• + *„, then the constructor type const (v [i], “») donotes 

a tagged tuple of type t,[ni ..... a,,]. , 

Polymorphism is expressed using the existential and universal types. A value of type 3a. t has typo t for 

some type a, and a value of type Va.t has type t for all types a. 

An object type Object(ei) is a recursive type definition denoting objects with description t. 


FIR expressions The FIR expressions are in a inostly-functional intermediate form where the order of 
evaluation is explicit . Atoms are values that are either constants or variables, and the other expressions are 
computed over the atoms. Function definitions are stored in an environment Z that also serves as a type 
assignment. The definitions are shown in Figure 4. 

Expressions include explicit coercions and arithmetic as unary and binary operators. 
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Type 

Description 

t boxed(Z) 

Boxed Integers 

1 to....-} 

Integer enumerations 

1 Zh- Zi 6 , Z32, 

Native integers 

| float 

Floating-point numbers 

| (ti -4 t 

Function type 

const ( ??[*], ti f„) 

Constructor type 

1 t n ) 

Tuple type 

| / array 

Array type 

| data 

Unsafe data 

| r»,0,... 

Polymorphic type variables 

1 V 

Typo variables 

I 

Type application 

| 3 a.t 

Existential types 

| Vo A 

Universal types 

| v.i 

Abstract type 

| Object 

Object type 

d Aa 1, . . . ,a n ti H + tm 

Type abstraction 

7 v = d \ a 

T ::= 71,. . .,7„ 

Type contexts 


Fig. 3 . The FIR type system 


The ‘’ext” call represents a call to the runtime, providing a method to issue system calls. Type definitions 
for system calls are provided as part of the compiler configuration, to ensure type safety. The tailcall provides 
the only other means for calling a function. 

The “match” construction allows pattern matching against a constant set of numbers, represented as a 
list of intervals. Each match case defines a set s and an expression e. Operationally, the pattern match selects 
the first case (s,, e ? ) such that a E Si , and evaluates the expression e*. An inexhaustive match is a type error. 

The “alloc” operation is used for allocation of tuples, constructors, arrays, or data arrays. 

The array operations define primitives to load and store values in arrays. The store operation is the only 
non-functional primitive in the language. 

The “assert statement asserts that a predicate must be true. The runtime uses these predicates to 
validate array bounds, and other runtime properties. 


3.3 Phobos 

The Phobos parser provides dynamic and extensible parsing. Languages can be augmented with new syntax 
and semantics, and added to the system runtime dynamically. 

The central issue in an extensible parser is the representation of semantic actions — the programs that 
describe, for each clause in the grammar, how to form the abstract syntax tree. Our approach is to represent 
all intermediate forms as terms, and to use the MetaPRL term rewriter to define semantic actions. 

For example, Figure 5 shows the language description of simple arithmetic expressions including factorials. 
The entire description is represented as a language module, which can be incrementally refined and extended 
in inheriting modules. Based on this language module, Phobos can lex and parse a source string and return 
a MetaPRL term that encodes its semantic meaning. 

A Phobos language module consists of 

- Term declarations: importing terms from existing MetaPRL modules. In the above example, the arith- 
metic meta operations are imported from Base_meta, a standard MetaPRL module that defines basic 
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Dcfinit ion 
a ::= nil(f) 

| boxed(z) 

I i 


unop | ' i • ■ • 

binop | | | | * 


c ::= .s — > f 

p ::= lwum/.s(i’[«i . ■ - n 2]) 

| /.s-/?iuc£t0n(r’[a]) 

alloc ::= (a 1 .... - «u) : * 

| const (?;[« 1 «n]i 0 : t 
| array (ai . «•>? : 

| m alloc (a) 

e ::= let v t = unop a in e 
| let u: t — a\ binop a 2 in r 
| let v t = (ext "s" : 0 («i • 

| i’(«i «n) 

| match a withci | • • * | c n 
| let v = alloc in c 
| let r\ t = a 1 [a 2] in e 
| a 1 [a-j] : t #13; c 
| assert (p); r 

a ::= c : t 

V* ::= < 7 l, . . . , tT n 


Descri ption 

The ”1111" value for type”/ 
Boxed integer constants 
Native integer constants 
Floating-point constants 
Variables 

Unary operations 
Binary operations 

Integer interval set 
Matc h case 

Bounds check 
Pointer ( heck 
Function cheek 

Tuple allocation 
Constructor allocation 
Array allocation 
Malloe 

Unary operations 
binary operations 
«.„) in c Calls to the runtime 
Tail call 

Set membership 

Allocation 

Load 

Store 

Assertion 

Variable type 
Function definition 
Variable environment 


Fig. 4. FIR expressions 


operations on numbers and simple conversions for their simplification. Term declarations serve t he pur- 
pose of verification and proper scoping within MetaPRL modules. Terms do not have to be declared if 
they are explicitly named with their parent module, for example Itt_int_base Inumber. 

Lexical information : terminal symbols are named and defined by their corresponding regular expressions. 
Upon successfully matching a regular expression, the resulting token is represented as __token__ LptsJU P° s > 
where p stores the matched string, and ’pos its source position. This term can be given further meaning 
by an optional lexical rewrite. In the example, numbers are rewritten to MetaPRL number terms. 
Precedence rules: used to define precedence and associativity of terminal symbols and production rules. 
Grammar : Expressed in BNF, each production may contain a list of rewrites that define the corresponding 
semantic action. If more than one rewrite is given, the first matching rewrite is carried out during parsing. 

If no rewrite is given, a default rewrite is used that builds a tuple term from the right-hand side’. 
Post-parsing rewrites : Possibly multiple sections of rewrites that are executed in sequential order after 
parsing. In the above example, the two rewrites are responsible for replacing a fact term with its actua 
value bv unfolding factorials into multiplications. At the time of applying these rewrites, the Metal RL 
refiner contains several “built-in” conversions that, for example, reduce the met a arithmetic terms. 

Optimizations : Optional target patterns for optimizations. 
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Module Calculator 

Terms -extend "Base_meta" { 

declare meta_sum{ 5 el ; ’e2}, meta.dif f { ’ el ; 7 e2> 

declare meta_prod{ * el ; ’e2}, meta_quot{ ’ el ; ’e2} 

} 

Terms -extend { 
declare fact{’e} 

> 

Tokens -longest { 

NUM = M [1-9] [0-9] * " { token [p:s]{’pos} -> Itt_int_base ! number [p : n] } 

TIMES = {> 

DIV = "/" {> 

PLUS = " + " {} 

MINUS = {> 

LPAREN = "(" {} 

RPAREN = {} 

BANG = "!" {> 

* EOL = "Wn" {} 

* SPACE = " " {> 

> 

'/♦left PLUS MINUS 
'/.left TIMES DIV 
'/.left LPAREN RPAREN 
'/.left BANG 

Grammar -start e { 
e : := NUM 

I e PLUS e 
I e MINUS e 
I e TIMES e 
I e DIV e 
I e BANG 

I LPAREN e RPAREN 

} 

Rewrites { 

fact{l} -> 1 

fact { * number} -> raeta_prod{ ’number ; f act {met a_diff{ ’number ; 1}}} 


{} 

{ ’el PLUS ’e2 -> meta_sum{ ’ el ; ’e2} } 

{ ’el MINUS ’e2 -> meta.diff { ’ el ; ’e2} } 

{ ’el TIMES ’e2 -> meta_prod{ ’ el ; ’e2} } 

{ ’el DIV ’e2 -> meta_quot{ ’ el ; ’e2} > 

{ ’e BANG -> fact{’e> } 

{ LPAREN ’e RPAREN -> ’e } 


Fig. 5. A grammar for simple arithmetic with factorials. 
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Given our language 1 module'. 1+2+3+4! yields Itt_int_base ! number [30 .n] , a 
representing the number 30. 


MetaPRL number term 


4 System Architecture 

There are several technical issues in integrating these systems. The first issue is defining a shared language' 
for MetaPRL and Mojave (Phobos and MetaPRL already share a common language of terms). Next, m order 
for MetaPRL to reason about Mojave programs, we have to formalize the language, including its operational 

semantics. 


4.1 FIR as a common language 

We are using the FIR as the common MetaPRL/Mojave language, for several reasons. First, all the front- 
ends including C, ML, and Java produce programs in FIR: if we can reason about the FIR. we can reason 
about programs produced by any of these languages. Second, the FIR has a precise semantics, where many 

of the source languages do not (for example, C). 

However, the disadvantage of using the FIR is that it is difficult in general to translate source-level 
specifications and proofs to their corresponding spec ifications and proofs at the FIR level. The optimization 
problem is not nearly so hard, and much of our c urrent work has been developing operational reasoning m 

MetaPRL about programs in the FIR . . 

The Mojave compiler does not use terms for its internal representation of programs. Lor communication 
with MetaPRL we develop “glue” code to translate between the Mojave FIR representation of a program, 
and the MetaPRL term representation of the program. This glue code is straightforward; for the remainder 
of the paper, we will assume programs are represented as terms. 


4.2 FIR term representation 

The MetaPRL term representation for FIR programs is straightforward. In most cases, the term that repre- 
sents an FIR expression has an explicit operator name (opname), and a set of subterms described recursively. 
We illustrate the translation wit h a few examples, using the notation [•] for the term representation of a 
FIR program. 

The atom values tagged with a name and any additional parameters. 

|uj = atomVarju} 

[*] = atomlntfi} 

[G 2 , signed] = atom Rawlntj int32; signedlnt; /} 

Expressions are a bit more interesting because of their binding structure. The term representation of an 
expression, in contrast to the ML representation, uses explicit binding in the form of higher-order abstract 
syntax [15]. As Pfenning mentions, the advantage of higher-order abstract syntax is that substitution and 
alpha-renaming are automatic. The disadvantage is that analyses that modify the binding in unusual ways 
become difficult to define. We illustrate the term syntax with the term for binary arithmetic. 

|let v : / = binop a >2 in e] = letBinop{ [/]; \bmop\\ |«i]; [^2]? ?? *M} 

The remaining terms follow the same general form, and we omit them here. 


4.3 Operational semantics 

The operational semantics of the FIR is defined using rewriting rules in MetaPRL. The actual operational 
definition is cpiite large because there are many combinations of arithmetic operations and values. However, 
the forms of definition are straightforward. For example, the operational rule for addition has the following 
general form, which we write using simplified pretty-printed notation. To be faithful to the implementation, 
we are using modular arithmetic. 
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(let r: t = atomlntf?} + atomlnt{j} in e[c}) -4 e[i + j] 

The control operator match has a more interesting definition. The' match operator is a pattern match of 
a number ? against a set of intervals. The number of interval cases is arbitrary, and reduction performs one* 
case analysis at a time. 


(match i with s -4 e | cases) 

— » (if i € s then c else match ? with cases ) 

Th(‘ int.enal s is represented as a list of closed intervals [?i i . i La], • • ■ , [ / , # i , / Ti r>], and the 1 membership 
operation is defined inductively. 

(i £ ([ j , k] :: interval)) -4 (/ < j A i < k) V ( i € interval) 

(i € [] ) -4 false 

Once again, the remainder of the operational semantics is straightforward, and we do not present it here. 

4.4 Models and usage 

The question of models is probably the most interesting topic in this translation. Ideally, we would develop 
a model of the FIR in a type theory or other higher-order logic, and then prove the operational semantics 
and typing rules. Note that a complete model would need to represent both partial functions and general 
recursive types. We have not developed this model, arid we presume that it is likely that we will need to 
restrict validation to a fragment of the calculus that has a well-defined formal model. In the meantime, we 
treat the operational semantics axiomatically. 

As Figure 1 illustrates, there are currently two major ways that, we use the MctaPRL/Mojave system. The 
(i) path uses the Mojave front-ends to generate FIR code, which is then passed to MetaPRL for optimization. 
The (ii) path produces FIR from a Phobos description, optimizes it, and passes it to the compiler for code 
generation. 

5 Examples 

We illustrate the system with two optimizations. The MetaPRL/ Mojave systems, including examples, can 
be downloaded from http://www.metaprl.org and http://mojave.cs.caltech.edu. 


5.1 Dead-code elimination 

Some standard code transformations are incredibly easy to define using term rewriting. Dead-code elimination 
is one of the simplest. The idea of dead-code elimination is to remove any code that does not affect the result 
of a computation. The problem is not computable in general, although we can develop proof procedures to 
catch a fairly broad set. The usual approximation is to use a syntactic characterization: the sub-expression e\ 
in let v: t — e x in p 2 is dead if v is not free in e 2 . Second-order term rewriting makes this easy to characterize. 
The following rewrites can be derived as theorems in MetaPRL: 

(let v : t — unop a in e) -4 e 
(let v : t = a,\ binop a% in e) -4 e 
(let v ~ alloc in e) -4 e 
(let?;: t = «i [«a] in e) — > e 

Dead-code elimination is then performed by normalizing the program with respect to these rewrites. 
Note that the expression e in the redex does not mention the variable v, which means that v is not allowed 
to appear free in c (the second-order pattern e[v] would have allowed v to appear in e, and would not 
he provable [13]). Also, note that the first-order definition using substitution would not be as useful for 
dead-code elimination because the rule does not specify explicitly that the variable v is dead. 
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(let?.’: t = unop a in c) — > r[o/r] 

There are two main differences between this formal dead code elimination (using path (ii) in Figure 1). 
and the standard dead-code elimination (using path (i)). First, the formal definition is much smaller the 
Mojave dead-code elimination phase is some 700 lines of OCaml code. Second, the OCaml implementation 
is also much more general, because it makes use of global program properties. For example, the OCaml 
implementation performs dead-argument elimination, where a function parameter can be eliminated if it is 
never used. This requires modification of all calls to the function through the program, a global operation 
that is difficult to perform using term rewriting. 

5.2 Partial evaluation 

The next example illustrates a simple, but noil-trivial, application of partial evaluation. Consider the following 
FIR code (we omit the types for clarity). The power function computes the value res * .r v , and passes it to 
the continuation coni. The power 5 function computes the specific case where ies 1 and // o. 

let power (res. x. y, cont) = 

if y = 0 then 

cont (res) 

else 

let res’ = res * x in 
let y‘ = y - 1 in 

power (res', x, v\ cont) 

let power5 (x, cont) = 
power(l, x, 5. cont) 

inline power(res, x, mnnber[i], cont) 

For this example, we would like to “unroll” the definition of power5 to a sequence of 4 multiplications 
x * x * x * x * x. The programming language, defined in Phobos. includes the inline extension where the 
programmer can indicate patterns that should be expanded using the inline keyword. For the example above, 
the inline instruction specifies that a call to the power function should be expanded when its third argument 
is a number. 

Based on this information, the MetaPRL system constructs a rewrite to force the unfolding. 

let power (res, x, number [i], cont) — > 
if number[i] = 0 then 
cont (res ) 

else 

let res’ = res * x in 
let y 1 = number[i] - 1 in 
power (res', x, y\ cont) 

Next, power 5 is normalized relative to the rewrite, and all calls to the power function with a constant 
exponent are inlined. The final definition of the powerS function is as follows. 

let powero(x, cont) = 
let xl = x * x in 
let x2 = xl * x in 
let x3 = x2 * x in 
let x4 = x3 * x in 
cont.(x4) 
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The optimized rode produced by MetaPRL is still suboptimal; if we assume that multiplication is associa- 
tive. the number of multiplications can be reduced to three. We have not implemented partial evaluation as 
a compiler phase* in path (i). Partial evaluation is most naturally expressed using the operational semantics 
of the* program: any implementation would needlessly reimplement program evaluation. 

6 Conclusion and Future Work 

The work presented in this paper demonstrates the principle of formal integrated design environments, but 
the integration is far from complete. Among the next steps are: 1) a complete formalization of the operational 
semantics and type system for the FIR, 2) a more general framework for performing partial evaluation. The 
Mojave compiler architecture has many (around 30) stages of program transformation and optimizat ion. It 
seems likely that many of these transformations can be significantly simplified by implementing them in the 
theorem prover. Another important direction is “bootstrapping. r Currently, MetaPRL is still layered over 
the OCaml compiler because the Mojave implementation of ML does not include a module system. Removal 
of this obstacle would enable complete integration of the formal design environment. 
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Abstract. This document describes part of an effort to achieve in Nuprl a practical reflection of 
its expression syntax. This reflection is done at the granularity of the operators; in particular, each 
operator of the syntax is denoted by another operator of the same syntax. Further, the syntax has 
binding operators, and we organize reflection not around the concrete binding syntax, but instead, 
around flit' abstract higher-order syntax. We formulate and prove the correctness of a core rule for 
inferring well-formedness of instances of operator-denoting operatois. 


1 Introduction 

This work is part of an overall effort to got a practical reflection of syntax, computation and proof in 
Nuprl [4,1.3]. Reflecting syntax in a logical system entails writing proof rules that express that reflection, 
i.e. establishing an inferential connection between the actual syntax used and the meta-tc mis suppost dl\ 
referring to it. 

Operator-denoting operators are called shifted operators: if an operator x denotes operator y. t k ii .r is 
called a shifted y, and will be typeset as y. For example, aj -_b denotes r + d if n denotes c and b denotes d. 
The plus operator denotes a function that takes two integers and returns an integer, and its shifted version 
denotes a function that, takes two terms and returns a term. The problem is what do we do with an operator 
that has a hound subterm: for example, Vx. P(x) is an operator that denotes a function taking a boolean or 
propositional function and returning a boolean or a proposition (its syntactic form is. of course, binding). 

The obvious choice for the semantics of the shifted version would be a function, V(.t. P ) that takes two 
expressions as input values: one for the hound name, and one for the body, and constructs the concrete V 
term. We will not pursue this direction. Instead, we shall adopt a higher-order abstract syntax [7], Going in 
this direction, we get the usual benefits of this approach over concrete syntax (or alternatives like de-Bruijn 
indexes), such as specified in [8]. But we get a further bonus: it allows us to retain the same binding structure 
as the operator being denoted. In particular, the single input argument for V has the same binding as V: it 
takes in a term- valued function as an argument. 

Implementing reflection in a programming language is usually done in a straightforward way: simply 
expose the implementation’s evaluation function so it is available to programs written in the language. 
However, in a logical setting this is usually not the chosen approach, and the result is usually limited in 
its usability to theoretical or toy examples. The best example is Godel numbers [5] which are good as a 
theoretical tool but not fit for an actual running system. Our goal is an eventual implementation that follows 
the same principle of exposing internal functionality: this is the outcome of operators being denoted by 
operators. The result is expected to be a system that has practical reflection implemented as is the situation 
in programming languages. 

This construction is intended for the Nuprl system, but we avoid relying on a specific substitution function, 
which makes this approach applicable in the general case. Relevant information about Nuprl terms is limited 
to their content: a Nuprl term contains an operator id, and a list of bound subterms, each containing a list of 
hound variables and a term. Throughout this text we use a more conventional notation, with the extension 
of using underlines for shifted operators. 

Returning to the question above: we begin by asking what is the semantics of V? The semantics of a 
concrete shifted V is the trivial one given above, but the semantics for V is more subtle. 


2 Semantics of Shifted Operators 

Since V is a binding operator, it takes a function as an argument. Our basic requirement is that F(t) be the 
result of the ‘All-Instantiation’ rule applied to Vx. F(x) and t. This means that F needs to he a substitution 
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function. So the semantics we adopt for Vx\ F{ x) is that it denotes the V formula whose predicate part is 
F(u) and whose hinder is a for some u almost . 

But which w? As usual we can avoid this question by using a higher-order abstract syntax, and say that 
what is denoted is actually the o-equi valence class of all such formulas where some appropriate' u could be 
found. From this point forth. wo use Term’ to refer to these 1 a-equivalenee classes rather than the concrete 
terms. 

Before going to the technical parts, lets consider how we might reason about this in the reflective logic. 
The first intuition is that proving that something is a Term depends only on having a quoted operator opid 
and on its subparts in a simple compositional way: 

h opid frT.fti ; V 2 .b>; . . . ; v^.b n ) € Term 

if v\ : Term I- b\ € Term 
¥2 : Term h fc-> £ Term 


; Term h b n 6 Term 

This set'ms hue. but it fails with bound variables. For example, the following can be proved: 

F A(.t. if x = 0 then 1 else 2) £ Term 

because x : Term h if x = 0 then 1 else 2 € Term 

The premise line is trivial, but the original statement is false, because the quoted A-term contains a function 
which is not a substitution function it is not a “template” function. In other words, there is no literally 
quoted term that this value stands for. 

When inspecting this term, we can compare it to similar but valid terms to see what went, wrong with 
this rule: 

1. Mx . if x — 0 then 1 else 2) 

2. A(xjf x = 0 then l else 1} 

3. Ax. if x = 0 then 1 else 2 

The two A-terrns are fine, because they’re built from substitution functions, and the last one is a simple 
Term — > Term function. The difference between these terms and the previous one indicates what, is wrong 
with the above rule: the bound variable should not be used as a value. It is a binding that should only be 
used in template holes, as there is no real value that this variable is ever bound to that can be used. In the 
valid examples, the first one did not use the bound value except for sticking it in its place. The second one 
almost used the value, but since the two branches are identical it is possible to avoid evaluating the test 
term; therefore it can be evaluated without using it,, and the last one is not a Term but a function on Terms, 
so it can use that value as usual. 

The conclusion is that a bound variable can be used only as an argument of a quoted term constructor. 
In other words, it can serve only as a value that is “computationally inert 1 ’, much like universe expressions 
in [2]. This is also similar to variables that, are bound by Scheme's syntax rules [6] they are template 
variables that can be used in syntactic structures to build new structures 1 . When put in this light, it seems 
that any attempt to get this property in a proof fails. The lesson from this is: variables bound by quoted 
operators do not behave like normal bindings in the sense that they do not provide any values usable on the 
normal Nuprl level and this is also true regarding universe expressions. 


3 Term Definition 

We take CTerms as concrete terms: the type of objects intended to be ordinary syntax objects with binding 
operators. A more precise definition is given later, in Section 5. To define the Term type, we also need to 

1 For example, in the template ((foo x) (bar x)). the identifier V is just a place holder that can he used to stick 
a value in a template; it is not possible to inspect its value. 
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introduce a predicate, is.subst. which is used to distinguish proper substitution functions. This predicate 
is defined in Section G. and it has specific rules which are introduced in Section G.l. 

As said above. Terms are defined over these CTerms: 

Term = CTerm//a 

Terms are constructed by shifted operators, which have the semantics of functions that create Terms from 
Term substitution functions. For example: 

X : {} : Term -4 Term | is.substi (/)}-> Term 

using a version of is_subst that works with one argument functions. Generally. is_subst„ is a predicate 
over Term"— ►Term. To simplify things, we drop the n when the context is clear. 

CVar is a subsets of CTerm, which contains only atomic variable terms. Correspondingly. Var = {{x} j 
x e CVar}, therefore Var C Term, since variables are o-equivalent only to themselves. Two assumptions that 
will be used in the following are that we have art infinite supply of distinct variables in CVar (and therefore 
in Var) and that there is at least one closed CTerm we can use. 


4 Operations, Assumptions, and Facts 

These are the operations that will be needed in the following text: 

•f taking the rt-equi valence class of an object. 

.[ choosing an element of an o-equivalence class. This is some function, such as one that chooses the 

first available variable names using lexicographic order. 

.[./.] standard capture-avoiding substitution on CTerms. It can be used to substitute for multiple variable's 
at one shot, provided that the number of supplied terms matches the number of variables, which are 

all distinct. 

• [■/■] substitution for Terms, which is defined using the above operations as: b|* r / r ! = ^HkIA’ 1][- 
newc var (•) returns a new CVar, i.e., newcvar(f) is neither free nor bound in t G CTerm. 
newvar(-) is similar to ncwcvar( ) but for Terms, defined as: newvar (.r ) — newc var(.r[)f. 
newcvar n (-) returns n new CVars. defined as: 
newc var i (:r) — newcvar(.r), 

newcvar n +i (x) — (let v -- newcvar,i(x) in ?■, newcvar(?J, x)). 
newvar,} ( •) returns n new Vars, defined in the same way as newcvar n ( ). 

We use versions of these operations that are generalized to any lists and tuples of input arguments in 
an obvious way. The newcvar(-) and newvar (•) operations are further extended to functions by plugging in 
some closed dummy term argument, (that we name k 0 ) and using the result. 

V/ : Term" -4 Term. newvar m (/) = newvar m (/(O n )) 

Below we will often justify things of the form a\= b\. by mentioning lemmas of the form a = rt b. without 

emphasizing this transition. _ n 

Note: an overline indicates the value is a tuple and a way to index its elements. For example, x : Var 
means that x is a list of n Vars, and that x, is the ith element of this list; that is, x is a function from 
/:!... len(T) to the ith element of x. 


4.1 Important Assumptions and Facts 

In this section we state several assumptions and derived facts about substitution the assumptions arc' 
not argued for, but we think that it is clear they are all true for any reasonable definition of substitution 
(one that respects the usual term binding structure). This allows us to take' substitution as given arid avoid 
getting into a specific implementation. These will be used in the following text. 
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★ 1 Vx : Term, x — x [ \ 

★2 Vx : CTerm. x — a xfL 

Tliis fact is mostly used when nested in a bigger term, see *4 below. 

★3 Vx : CVar. x = x\[ 

because x 6 CVar => x\[= {x}[= x. 

*4 VxT-xJ : CTerm”, 77 : CVar”, b : CTerm. x7 = rt x7 => b[¥[/v] — 0 b[x^/v\ 

Note that using this fact, *2 can be used in a subterm of an a-equality, since: Vt,x : CTerm. t = n f[.rf|/x] 
★5 V 6 1 , b ‘2 : CTerm. 1 : CTerm”, v : CVar”. b { = a => /q [f/77] = a 

note that 77 is the same on both sides (free variables in the body are not changed). 

★6 Vt : CTerm, Tf : CTerm” 1 , x7 : CTerm” 2 , 777, 77 : CVar” 1 , 777 : CVar” 2 . 
the sequence 777, 777 are* distinct 77 are* distinct, not free in t.xT 

=> JT/W, wj] =n /[t7,X2/vr,W][«r/u] 

This is simple to verify: 

t[77, xo/TTf. r^prT/tZ] 

(any of u do not occur free in /.} — a ju], X 2 [ X[ j //] j V\ , C 2 ] 

(77 are distinct) = a t[x\, X 2 [xj f u]/V [ , Th] 

(any of 77 do not appear in .?•>) — n t[X [ , X 2 / ? ? l , C 2 ] 

Note that it is easy to show that such a 77 exists by choosing it as: 
let 77 = newcvar ril (/, xj. . . .) 

★7 Vf : Term, x7 : Term” 1 , x7 : Term” 2 , 777, 77 : Var” 1 , TJo : Var” 2 . 

the sequence 777? 77J are distinct & 77 are distinct, not free in /. xT 

Again, verifying this is simple: from *G we know that 
1/wTl. Wl][5Tl/wl] f = t L[?n, xj l/rri, WL]r, 

so: 

<[«>^/w>w 2 i£o/«i = <i[«u *2 i/wru wi]rt[^ri/«i]r 

(*2, *5) = tt[ul,Xjt/ijn,l>2l][xrL/“l]r 

(by the use of *6 above) — t . [ [.T i [ , X t \ f V \ V’j [] f 

= t[5T, xi/vi, uaj 

A similar note holds here: it is easy to show that such a 77 exists if it is chosen as: 
let 77 = newcvar ni ( t\ , aJJL • . .[)\= newvar„, (t, 

★8 Vc : CTerm, 77, 71 : CVar”, s, t : CTerm”. 

71 are not free in c except for 77 => c[^/c][7/ 71] — fi c[s\t/u]/v] 

Note that the 77 exception is usually not needed. 

★9 Vc : Term, 77,77 : Var”, s, t : Term”. 

77 are not free in c except for 77 => cp/77jp/77] = c[sp/77j/77] 

This is easily shown by *2 and the definition of •[•/•], using the previous fact. 

A general intuition that arises from these facts and others, is that Term values are indeed isomorphic to 
CTerms: as long as there are no u dirtv” concrete tricks played by using names of bound variables, facts that 
hold for CTerms will have corresponding versions for Terms. 

5 Definitions of Shifted Operators 

In the general case, a shifted operator id, opid , is defined as a function that takes in some substitution 
functions (determined by is_subst) of some antics, and returns a Term value. This is done in the obvious 
way: each of the substitution functions is used to plug in new variables; then the results, with the chosen 
variables, are all packaged into a CTerm; and finally, the a-equivalence class of this result produces the 
resulting Term. The actual representation is not too important we could go with pairs and lists. For 
example: 


A(/) = (‘A\[<[newvar(/)l],/(ncwvar(/))l)])t 
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but this gets too complex in the general ease (and it makes analysis hard, since we should know if a pair 

stands for a bound term, a term, or a pair of terms). 

Instead, we use some types and abstract operations, which avoids committing us to some representation. 

Th<> additional types we need are: 

- Opld will be used for term name labels; 

- BndCTerm„ is a bound CTerm (where a : N) - - packaging a CTerm with a distinct CVars. 

BndCTerms arc created with a mkBndCTerm constructor**: 

mkBndCTerm G (i : N — > (1 . ■ ■ a CVar) — > CTerm — > BndCTerm (i 
An alternate syntax for mkBndCTerm can be more natural when a is known: 

mkBndCTerm(J. t) stands for mkBndCTerm(len(r). (At. x,),t) 


CTerms are created with mkCTerm: 


mkCTerm € Opld -> n : N 

-4 a : ( 1 . . . n -4 N) 

-4 (i : 1 • - . n -4 BndCTerm Qt ) 
— >• CTerm 


An alternate syntax for this which can be more natural when ti , a are known is. 

mkCTerm(o, [mkBndCTerm(.f i . t \ ), . . . . mkBndCTerm( x n . t n )] ) 


which can be used instead of 

mkCTerm(o. n, (AT len(x7)), (AT mkBndCTerm^ ti))) 

The next thing we need is a type which is the subset of Term n -»Term functions that are substitution 
functions (using the is_subst predicate): 

SubstFunCn = {/ : Term ?i ->Term | is_subst„(/)} 

Now we have reached the point where we can finally define a mkTerm constructor for Terms which uses 
mkCTerm: 


mkTerm G Opld -4 n : N 

-4 a : ( 1 . . . n -4 N ) 

->(/': 1 .. . n -4 SubstFunc ni ) 
-4 Term 


This function is defined as: 

mkTerm(o,n, a, /) = _ 

mkCTerm(o, n. a, AT let x = newvar ai (fi) mkBndCTerm(xt, f, (r*)[)) \ 

and the alternate syntax for this is: 

mkTerm(o, [(a\, f \), . . . . ( a ri . /„)]) 

which stands for 

mkTerm(o, n. AT a,, AT /,) = mkTerm(o, a, / ) 

2 We US e the notation x : A -4 lh to denote functions on A such that Vr : A. f(x) € B x , a type which is more 
conventionally denoted by Fix : A. B x . 
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A shifted operator is a Term constructor which uses mkTerm with souk 1 fixed operator name and arity 
list. For example. A' and art* defined as: 

A(/) = mkTerm^A’. [(1. /)]). £(f„ </) = mkTerm(*r\ [(0. /). (1. </)]) 

Note that since mkTerm is curried, a shifted operator is made by specifying the first three inputs: mkTerm(o, n.a). 
In addition to the assumptions and facts introduced in Section 4.1. we further assume the following: 

*10 We specify out* way that substitution interacts with CTerms for all /, k , if it is true that 

if v/t is free in /, then none of x~ are free in either or r* 

then 3 , 

mk CTerm (o, », a, XL mkBndCTerm(T7, =« mkCTerm(o, n, a, A i. mkBndCTerm(T7. /,[r/r])) 

To see why it is true using any reasonable definition of substitution, it is simpler to first see that a 
precondition that could bo used is that none of xj occur free* in r,F; this is too restrictive for our future 
needs but the explanation is somewhat, similar. 

First of all, if is not. free in ti, then there is no need for any restriction, since it dot's not have any 
effect on the result. Now, if it does appear in then it is enough to have two guarantees for the above 
to remain an a-equality: (a) if none of xi are free in /> then capture by T7 is impossible: (h) if ??/. is not 
in x], then none of t.h(* v k will not get “screened out” in the body. 

• A fact similar to this assumption also holds for Terms if none of T7 occur free in r, F, ) then: 

mkTerm(o, w, «, A/. /,:)[F/F] — mkTerm(o, n, a. A*. A3. /,(3)[F/Fj) 

However, it turns out that this fact is not needed, so no proof is given. 

★11 A simple fact about renaming bound variables: 

VT7,37 : CVar”. xj are distinct & ~z[ are distinct & zj are not free in b, 

=> mkCTerm(o, n, a. Xi. mkBndCTerm(T7, 6,-)) 

= rv mkCTerm(o, ?).,«, Xi. mkBndCTerm(37, b t [zi/x 7])) 

6 Defining is_subst 

A function is a substitution function iff there exists an appropriate substitution that it is equivalent to. First , 
we describe this using CTerms, since we know how substitutions work on them: 

is_subst n (/) = 3 b : CTerm. 3F : CVar”. V? : CTerm”. f(t\) = b\t/v]\ (1) 

Note that / returns a Term which is an a-equivalerice class, so we have an equality rather than an a-equality. 
This should be equivalent to directly using a Term argument for /: 

is_subst„(/) = 3 b : CTerm. 3F : CVar”. Vr : Term”. f(r) = 6[r[/F][ (2) 

We should show that. Vfr : CTerm. VF : CTerm”, the two sub-expressions are equivalent. 

(1) =£> (2) Instantiate t with the chosen F[: 

/(r) = /(fir) ( = b[f[/v\\ 

(2) => (1) Instantiate f with 1 f and we get: 

f(t\) = (>{i UM*= 4 b[t/v] r 

We can now try to use a version that has all Term types and no CTerm types, using the o-terms substi- 
tution, •[*/■]: 

is_subst n (/) = 3 b a : Term. 3F7 : Var”. : Term”, ffc) = b a [Li/T^j (3) 

Now, verify that this is indeed equivalent to the other two definitions: 

3 Note that the? a-equality is needed only because the substitution definition might introduce arbitrary renamings. 
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(2) => (3) Let b a = b\,i% = v f, pick some t„, and instantiate r with it: 

f{l~) = 6p^l/r]r= ^L[UML]f= 1 

(*) is true because of *2 (with f>). *3 (with e), and *5 (with i ). 

(3) => (2) Let b = b a [ . v = v^[, pick some r, and instantiate t„ with it: 

/(f) balf/1 % ] = 6„l[rL/nTL]r= )>[rl/v}\ 

6.1 The is_subst Rules 

Now that we have a reasonable definition of is_subst, we define key rules which use is.subst to prove that 
something is a proper Term. These rules turn out to be quite simple there are only two eases: 

• H \~ is_subst(j , i . ^2 -t'i) 

• H is_subst(x. opid (ITT- bi ; * • • ;?/»• b n )) wlu’re opjd is sonic quoted opid 

H F is_subst(x, y\. b\) 

H h is_subst(x r , y2' b>) 


H h is_subst(x, y n . b n ) 

Note that this is enough for proving the validity of any Term value: for example, quoted constants succeeds 
immediately since their opid is quoted and they have no subterms. Proving t G Term is achieved by showing 
is_subst(. t). (Of course, this is not a complete set. of rules, since there are more cases where we have general 
Term expressions that are not constants.) 

6.2 Justifying the is.subst Rules 
The validity of the first rule amounts to this: 

Vn, i : N + . i < n => is-subst fl (7r^ ) 

which is easily verified. Choose distinct v = v\ .... . v n variables, and let b — 7r N (e) — Then. V# 
Term". n l n (t) = Vjft/v] is true by the definition of ttJ,, of *[•/*!• and the distinctness of v. 

Our main result will be formulating and proving the validity of the second rule, but this formulation requires 
some preparation. First, recall that the type of mkTerm is: 

Opid -» n : N -> a : (1 . . . n -> N) ->(?*: 1 ... n -> SubstFunc ft , ) Term 

Note that, as said earlier, a shifted operator is the result of applying mkTerm on the first three arguments, 
since they define the operator symbol and the list of arities it expects. For example. 

A = mkTerm(‘A\ 1, (1)) H = mkTerm(‘I7\ 2, (0, 1)) 

So. a shifted operator has the following type, for some given o, n. and a: 

mkTerm (o, n,a) : (* : 1 . . . n — ► SubstFunc Qj ) — > Term 

Remember that the current goal is to conclude that for some shifted operator . opid . 

is_subst(x. opid (u7. b\, . . . , vT- b n )) 

if 

is_subst(x. IT- b\) ... & is.subst(x, u n . b n ) 
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We need to compose the opid function with an object that, will make the result, a Term* Term function 

(consuming the X], x k variables) which we them show is a substitution function. This means the function 

that is composed with opid should get a tuple of Tern/’ as input and return the vector of n substitution 
functions, built by consuming x. In short, we package all the necessary information in F : 

F : Tern/ — ► (/ : 1 . . . n , — * SubstFunc a , ) 


so we get the expected: 


mkTerm(o, n, a) o F : Terrr/ — >Term 


Now for the main result the validity of the second rule may be formulated thus: 

V o : Opld, n : N, a : (1 . . . n -> N), k : N, 

F : Terrr/ —>(?■: 1 . . . n SubstFunc 0< ). 

Vi : 1 ■ ■ .n.. is_subst*+ a . (\ {k) ts. xs. F(ts)(i)(xs)) 

=> is_subst*(mkTerm(o, n,a) of) 

where (\ {k) x, y. B(x , y))(u u .... «*+„) = B{(u x u k ). (u k+u .... «*+„)). 4 

Proof. Assume o, n. a , k. and F are given as specified. We also assume that the constructed functions are 
substitution functions; therefore, for every 1 < i < n we get c : Term, uj : Var*. Wj : Var rtt such that: 

Vrj,....rl,r : Term. F(rJ , . . . . r|)(i)(rjf , . . . , r'f ti ) = 


• Let 7 : Terrr/ be some k Terms, 

• let x7 = newvar ai (F(t)(i)), 

• and let s = newvar* (F*. xf. .... 3v) . 


Now we can proceed: our goal due to the definition of is_subst. is to derive* an equality of the form 

(mkTerm(o, n, a) o F)(t) = Z?|7/X] 

where, and this will be the tricky part, B and A are independent of the input. 7. So: 

(mkTerin(o, n. a) o F)(t) = 

= mkTerm(o, n, a, F(i)) 

(mkTerm def. ) = mkCTerm(o, n , a, \i. mkBndCTerm(x7U F(t)(i)(xJ)[))\ 

( F's fan) - mkCTerm(o, n. a, Xi. mkBndCTerm(x7i, c,|7, x7/U7, Ffjt))! 

( *7) = mkCTerm(o, n, a, Xi. mkBndCTerm(x7t, <"*[*, xT/uJ, Wjp/sjl))f 
(-I7-I def.) = rakCTerm(o, n.a, Xi. mkBndCTerm(x7U <*[*, xj/wj, W] Lpl/^L] T l ) ) T 
{* 2 ) = mkCTerm(o, n, a, Xi. mkBndCTerm(x7L, *7/^7? *T]LPl/sl]))l 

MO, see below) = mkCTerm(o, n. a, Xi. mkBndCTerm(x7L, <‘ip* x7/*Z7, W]l))[?l/«l] \ 

(*2) = mkCTerm(o,n,a, AT mkBndCTerm(x7l , c-i p, x7/w7, Wj l) ) 1 1[* IM] f 
('17*1 def.) — mkCTerm(o, n,a, AT mkBndCTerm(x7l, x7/n7,TTll))t|7//iJ 

In the above, making sure ★lO applies needs some care. Assume that for some jj., the variable sj [ is free in 
the Ith body, which is c/[s, xi/ui,vi][. We need to make sure in this case that xj[ is not free in either t.j[ or 
• s jl* The latter is trivial by the choice of s (and holds for all indexes), but the former is not obvious. What 
we do know about x7| is its definition: 


xd= newvar a/ (F(0(0)l= newvar 0| (c,[L 0 ai /ui,vf])[ 

4 Note that this special form of A could be avoided if the fourth input type to mkTerm would take the terms first and 
then the index (instead of the SubstFunc 0i ), but that would require a special composition operation instead. 
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but since Hj[ is free in c,[s, xj/uj. TvJlAhen u,j[ must, appear in c,[; therefore, the choice of .r,l above must 
pick variables that do not appear in 1 j l so we re safe. 

Going back to the main proof, the last term of the equality chain built so far was: 

mkCTermfo, n, a, At. mkBndCTermfjql, e,-[*. xT/uT, th]l))[p/- s ] 

which has the Bp/X] structure that were looking for, but were not finished because both the D and the A 
parts depend on 7 rq is defined in terms of t. s is defined in terms of TJ. and both B and A parts contain 

instances of s (and B actually contains x, as well). _ _ — 

So we choose 7-independent values now: let x\ = newvar 0| (e,) and let s' = newvar* (r. x\ . . . . . r k ). we also 
need to show that in the above, using t',.7 instead of xj- « is still the same value. In an attempt to simplify 
this we now choose n sets of variables IT € Term"',..., 5^ € Term"”, which are completely fresh: they do 
not appear in anything mentioned so far, including t. 

Now, back to otir equality chain which left off at: 

= mkCTermfo, n. a. XL mkBndCTermfTTf . c, [s. rq /tq • o] l ) ) t P/*] 


= mkCTermfo, n. a. At. mkBndCTermfs, [, r,[.s\ Zj/ui, c,]l))fp/«] 

Next, we use substitution to get s' inside s art 1 distinct, s' are distinct, and s' does not occur in 2 

= mkCTermfo. ti.a. XL nkBndCTermfsiU G l* 7 !#/* 7 ]. Sf l*/F]/l<7, W] D) f P/«] 

Because s' does not occur free in c, , this would be the expansion of the following substitution by *9 
= mkCTermfo. n.a, XL mkBndCTermfzJl, Cj[s', zj/uj, «7JI*/ • s 'Jl))fP/' s 'l 
Combining •[■/■] and *2 we get: 

= mkCTermfo. n.a, XL mkBndCTermfliUGp', IT/uJ, c7lL[^L/ A ''L]))fP/«l 
IJ do not occur in either s or s' so we can use *10: 

= mkCTermfo. n, a, At . mkBndCTermfTJ f, c< [s' , fl/uj, h] L) ) L] f P/*J 


Again, using -[-/■] and *2: 

= mkCTermfo, n, a, Xi. mkBndCTerm(17i,c,[.s',T7/i77,c7]L))fP/ s ']P/ s l 

Now, 5 does not appear in the mkCTerm except possibly for F (because we know it is not in c, or IT), so using 
*9 we get: 

- mkCTermfo, n, a, A i. mkBndCTermflff.Cip', 27/u7.G]f))[[Sp/s]/.s'] 

= mkCTermfo, n, a. At. mkBndCTermfrqf, c,[.s', Zj/iti, t'ilDHp/s'] 

Finally, using *11 we get: 

= mkCTermfo, n, a, At. mkBndCTerm(x'L,c,[.s',.r'/h7,T7]l))rP/- s 'l 

Our final term has the desired Bp/ A'] form, and now the B and the A parts are independent of 7. This is 
because: 

• i' depends only on c,; 

• F depends only on x) and r. and therefore only on c; 

• and u7 and vT. just like r, were derived from the assumption that the inputs are substitution functions. 


QED. 
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7 Conclusions 

The construction of the Term type was done to facilitate exposing internal Nuprl functionality to Nuprl 
users, which, it is hoped, will lead to a lightweight reflection implementation. We have shown the plausibility 
of basing logical reflection on higher-order abstract syntax, where each syntactic operator is denoted directly 
by another operator. 

We are continuing the implementation of reflection in the Nuprl system along these lines, and hope to soon 
test this conjecture. The core rules reflecting syntax that we showed correct hero, are already implemented, 
reusing existing internal functionality, without involving concrete syntax. Initial examples have indicated 
that it is, in fact, useful. 
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(Extended Abstract) 
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Australia 

DSTO’s DOVE project [2] aims to provide easy-to-use tools for the analysis and evaluation of criti- 
cal defence systems. The current DOVE tool provides a graphical front-end to a state-machine reasoning 
environment developed in the Isahelle/HOL [4] environment. 

- It allows the user to interact, with a design in a highly visual way. performing many design, animation and 
proof activities through direct manipulation of a graphical presentation of the state-machine topology. 

- The X Isabelle component of DOVE provides a graphical environment for managing the construction and 
execution of tactical proof-scripts. 

- It provides the user with a comprehensive database of the state-machine design, including definitions of 
all the transitions, variables, constants, and properties associated with the design. 

- It. allows the user to generate a high-quality presentation of the design in PDF format via the D I p.\ 
document preparation system [3]. 

Experience in the use of DO\ E has suggested a number of possible approaches to impro\ ing the DO\ E 
tool. 

- Many critical systems involve complex interactions between numerous components. DOVE would benefit 
greatly from support for the hierarchical decomposition of designs and analysis activities. 

- Many critical systems involve analog components, concurrency, stochastic and real-time interactions. An 
ability to treat such issues would greatly enhance the scope of the tool. 

- High assurance development standards require the generation of numerous documents describing various 
formal analyses of a design. Being able to generate a number of different documents from a single formal 
design, in various formats and for various audiences would be of great value to DO\ E users. 

- Providing true assurance in a design involves the effective communication of the results of the analysis 
process to a human audience. This is a particular challenge for formal proofs in general and is nearly 
impossible where proofs are generated through the application of tactical programs as is the case in 
the current version of DOVE. In addition tactical proofs are extremely brittle and difficult to maintain. 
Proofs need to be structured in a manner more natural to the human reader and at a level of detail which 
ensures the communication of the salient points without overwhelming the user with arcane points of 
formal logic. If possible proofs should also benefit from graphical comprehension aids. 

_ The unstructured input of formal mathematical text, can be a painstaking process even for the most 
experienced of users. An ability to assist and direct the construction of formulae is critical to the general 
adoption of a formal analysis tool. A related point is the need to provide screen support for the many 
and varied mathematical symbols and notations demanded by mathematically advanced users. 

- As a formal model grows, the problems associated with any large data set become apparent. The user 
spends increasing amounts of time and effort searching for the information necessary to make progress. 
Tool support for the management of the design database is critical to the efficient performance of formal 
analysis techniques. 

Concurrently with the development of the DOVE tool, important improvements have been made to the 
Isabelle environment itself. 
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- The Isar environment [6] now provides a literate and interactive environment for theory and proof 
development and presentation. Isar proof texts represent a significant improvement, over tactical scripts, 
both in terms comprehensibility and in terms of maintainability. However, as Isar proofs now contain 
the statement of many intermediate facts, the need for tool support in the management of design and 
proof elements is once again made apparent . 

- The introduction of the Isatool tool [7] has provided Isabelle with a mechanism to structuring formal 
developments as sessions and also for assisting in the preparation of a (single) high-quality document 
presentation of a session. However, the need to generate many views and presentations of a single session 
has not been addressed. 

- Integration with the Emacs-based Proof-General [1] tool now offers tool-supported management, of inter- 
active theory-script execution. Unfortunately, the Proof-General environment ignores the hooks for tool 
support provided by Isabelle mechanisms such as the session concept, document generation, or impor- 
tantly the assume/show presentations of proof goals which could easily be auto-insert ed into the theory 
script. 

- Support for the screen and document presentation of a range of mathematical symbols has been pro- 
vided through integration with the X-Symbols[5] package. Unfortunately, this does little to address a 
fundamental problem with Isabelle, namely the strong coupling of formal syntax and mathematical pre- 
sentation. An illustrative example of this problem is the inability to make use of the letter ; o’ as a logical 
variable. The character has been co-opted to servo as a formal syntax for function composition. Such 
syntactic conflicts become more and more common as the size and complexity of the theory database' 
increases. 

With all of these factors and opportunities in mind, the DOVE project team has developed a fundamental 
re-design of the DOVE tool. We have identified the following priorities for the next generation of the DOVE 
tool. 

- The basic function of the tool is to be the preparation of design assurance documents for the evaluation 
and certification of critical systems. It should allow the user to construct any number of documents in 
essentially arbitrary formats from a single 1 project database. 

- The tool should allow the user to group and maintain all formal elements, indexes and documents related 
to a given project within a single project artifact. 

- The tool should include a structured, syntax-directed editing mode for formal mathematical input. This 
mode should allow the user to construct mathematical terms by making selections from a palette of 
available operators. 

- The tool should offer a decoupling of formal presentation and formal syntactic layers. This allows indi- 
vidual users the maximum of presentation freedom without modification of the formal syntactic layer, 
an especially inconvenient process for library and predefined theories. The user should be able to craft 
presentations using arbitrary user supplied character fonts. 

- The tool should provide powerful indexes and structured views of the modeling database. This is critical 
for the efficient use of the structured editor and should act as an enabling technology for powerful 
tool-support for a number of other user activities. 

- The architecture of the tool should enable the future extension of the tool with specialised modeling or 
reasoning environments. 

- The tool should include a reasoning environment for the analysis of hierarchies of processes, allowing the 
treatment of concurrency, real-time properties, and analog system components. 

- The specification of temporal properties should enjoy a graphical presentation and importantly the proof 
of temporal properties for state machines should be performed as much as possible through interactions 
with the graphical presentations of the temporal properties and/or the state machine itself. 

The next generation DOVE tool is currently in an advanced stage of design and initial prototype coding 
has begun on the following features. 

- An XML document style has been developed to encompass all elements of a design project., including 
formal mathematics, indexing, and multiple document views. 

- The graphical user interface and modeling database is being developed in Java. The use of an object- 
oriented programming language is expected to greatly simplify future extensions to the tool. 
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The basis of the tool is the design editor, which allows the user to interact with the formal design using a 
familiar don.mo.it construction metaphor. The design editor is based on the the Swing Document class, 
allowing it to be prototyped rapidly with an acceptable level of on-screen document, presentation. 

The design editor will also control user-interaction with the underlying Isabelle/Isar environment. The 
editor automatically generates legal Isabelle theory files from the design document and controls the 
interactive processing of these files. Control of theory processing will be maintained through a -proeessed- 
up-to' marker which is additional to the usual text entry cursor. The user controls theory processing by 
moving this logic cursor around the document. The design editor mediates with Isabelle/Isar. providing 
feedback to the user on the results of processing, particularly of errors encountered. 

Printed document presentation will be provided through the use of the L'TfcX document preparation 
system. Access to more sophisticated document construction features, such as precision mathematical 
typesetting and bibliographies, will be provided by allowing the verbatim insertion of DTfeX code into 

the generated E v TeX output. f , 

A structured mathematical editor is being prototyped with sophisticated support for the use of mat. he- 
matical fonts in the Truetvpe format. Mathematical input proceeds through the selection of constants, 
type constructors, syntactic operators, et cetem from palettes that list the defined elements from the 


appropriate class. . . 

- A symbolic presentation layer lias been incorporated into the structured editor, allowing the user to 
change the presentation of mathematical operators with a minimum of impact on the generated Isabelle 

- Sophisticated tools for the description of hierarchies of components have been developed m Isabelle, 
inspired bv the Z schema calculus and mathematical toolkit. 

- Isabelle support for the design and analysis of networks of input/output process has been developed. 
Dataflow-style diagrams will lie used to visualisation these network designs and to provide a graphical 
user-interface for their construction and manipulate. 

- Enhanced Isabelle support for real-analysis is being developed in collaboration with the Software Verifi- 
cation Research Centre (SVRC) at the University of Queensland. 

- Initial investigations into support for probabilistic programming techniques are being carried out m 
collaboration with Macquarie University. 
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Abstract. We consider the abstract command language of Dunne, and his account of general cor- 
rectness. We provide an operational interpretation of his abstract commands, and use the automated 
theorem proving system Isabelle to prove that this operational interpretation leads to Dunne’s seman- 
tics. 

Keywords: general correctness, abstract commands. 


1 Introduction 

General correctness was introduced as an alternative to partial correctness and total correctness by Jacobs 

Gries (1985) [5], see also Nelson (1989) [7]. Jacobs & Gries use a relational model, representing a program 
as a relation between initial states and final states: their space of final states includes jL, representing 
non- termination. In this way they can distinguish when a program guarantees termination, guarantees non- 
termination. or neither. Neither partial correctness nor total correctness (alone) can do this. 

In [1] and [2], Dunne gives an account of general correctness, in which he gives a set of "abstract com- 
mands”, with associated semantics. For each abstract command, Dunne gives its semantics in terms of its 
termination condition, its weakest liberal precondition predicate and its frame , which is (loosely) the set of 
program variables which might be altered by the command. From these one can derive total-, partial- and 
general correctness semantics. 

We describe the abstract commands in terms of an operational interpretation similar to that of Jacobs 

Gries. We then use the automated prover Isabelle to show that this interpretation implies the semantics 
given by Dunne. We also use Isabelle to prove some of his more difficult results. This paper refers to results 
proved in Isabelle the code is available via the author’s home page (above). 

In [3], Gordon provided an operational interpretation of programs (commands), and used the HOL 
theorem prover to verify the axioms (rules) of Hoare logic. He explains in detail certain problematic aspects 
of such work, which we will allude to briefly. 

In [4], Harrison formalized Dijkstra's program logic in the HOL theorem prover, using a relation between 
states and outcomes to model commands. 

2 Modelling Commands and Conditions 

Commands Typically one models a command (or program) as a function acting on the machine state. A 
deterministic command which must terminate can be modelled as a function returning simply a single new 
machine state. A deterministic command which may or may not terminate could be modelled as a function 
which returns either a new state or nothing, representing the idea that a non-terminating command returns 
no result. However if we represent a non-deterministic program as a function which returns a set of new 
states, then this leaves us without a way of representing non-termination as one of several possible outcomes. 

We also want to represent commands which are infeasible. (These are a useful building-block, even if 
you don’t want, to write such programs, as Dunne discusses). In fact this, rather than non-termination, is 
naturally represented by a command returning no new state. 

The solution (Plotkin [8], also used by Harrison [4]) is to consider command outcomes , where an outcome 
is either termination in a new state or non-termination. 

Supported bv an Australian Research Council Large Grant 
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Conditions Boolean expressions, or conditions, on the machine state, occur in work such as tins m two 

“71 manv commands (such as if then else, or while do) incorporate conditions on the s ate. A 

state is typically represented as a function from the set of variable names to then values. The condition . 1 

such a command will most naturally be represented as text in the programming 

syntax tree, but as it will be capable of being evaluated in any machine state, we might 11 

function of type state -4 bool (and then we could treat the notion of state as an abstract on tity ) 

Secondly 1 condition Q can appear in an expression wlp(C.Q) (where w p means weakest liberal pre- 
condition).™ in (Hoare logic). It may be most natural to think of these as 0,1 stdte - 

(or functions of type state -4 bool). However the rule for wlp. and a related rule m Hoar, logic • an 


wlp(.r := E.Q) — Q[x E] 


{P[x:=E}} x:=£ {4} 


Bv (Mr : = E] we mean Q with occurrences of x replaced by E: various other authors write this as Q[x/E] 
0\E/x] (h-L Q(E/x). {E/x}Q, with, confusingly, both the first two being popular. The notion of snl^ 
st itu t h !n ^in dies.' ndes is meaningless when P and Q are arbitrary predicates on ? 

and Q to be expressions written in the command language, or something like it or as. sac, abstract s> 

"x trees, containing literal program variable names. Note that the language for these 

be able to express a condition like "no two different variables may have the same value (for. then, what 
would Q\x •= E\ mean?) However. P and Q may also contain logical variables, as m the following Hoai 
^ example (taken from Gordon (3, §5.0], where AM', Z denote program variables and x., denote logical 

VariabM (A = x A V = y)Z := A; A := A; Y := Z{ A = , A Y = x.} 

It is also worth noting at this point that where boolean expressions are used in abstract commands (such 
as the guarded command P -> A and the preconditioned command P|A) the boolean P is not treated a 
fragment of code but rather as an arbitrary predicate on the state. Thus, as is clear from Dunn, s treatment 
of these commands, the possibility of P looping or producing other than a single answer is not. < oiiskL . 

Gordon [3] discusses these issues. What this means for us now is that our analysis of many c oimnai . ( 
including assignment) can be performed at the level of abstraction where a boolean expression is modelled 
as a predicate on states, and a command is modelled as a function from states to sets of outcomes. The next 
section contains the analysis at t hat level. 

Frames Dunne has also defined that each abstract command has a frame. Loosely, this is the set of variables 
which “might” be affected. Note, however, that frame{x := x) = {x}. Also, from any comman. a new 
command mav be defined which has an enlarged frame but is otherwise the same. 

Stating the frame of a command does not contribute to a description of what the command does, so » w ^ 
can show, for example, that two commands behave the same way, without considering t. err rames. u 
work in this section proceeds on this basis. Note that the results are therefore subject to the proviso that 
two abstract commands are in fact not the same if their frames differ. We think that the relevant proof. 

about frames would be quite straightforward. . , . . t t . 

Consideration of literal commands and expressions and of the frames of commands is d. 
following section, as is that of the assignment command. 


3 Commands as transformations of state 


3.1 Monadic Types 

As mentioned, we model a command as a function from states to sets of outcomes. Here is the formal 
definition of the type outcome. 

datatype outcome = NonTerm 1 Term state 

So who,, we model sequencing of two commands .4 and B. wc firs, apply .4 to a give, .me, obtaining 
a set of outcomes, and wc must then apply B. a function of type stale outcome set. to the 
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outcomes obtained from .4. We can think of this as “extending* the function D to a function ext D of type 
outcome set outcome set When this can bo done in a way that satisfies certain conditions, we call the 
relationship between the types a “monad”. See Wadler [9] for further information on monads. 

In fact, this is an example of a compound monad. The type outcome, relative to the type state, is a monad, 
where the extension function, of type (state — r outcome) — > (outcome — r outcome) would he given by 

exto f NonTerm = NonTerm 
exto f (Term ,s) = fs 

For any type n, the type o set (the type of sets of things of type o) is also a monad, where the extension 
func tion, of type (o: — > a set) — > (a set — > a set), would he 1 given by 

exts f os = (J / o 

oEos 

Apart from the extension function, specification of a monad includes a unit function, which converts a 
\aluc of the base type, usually in a rather natural way, to a value of the monadic Type. For the two monads 
mentioned, wo have 


unito : state —> outcome units : a — > a set 

unito s = Term s units e— {c} 

Note also that the extension function is often called bind and written in infix format (as in 191). so ext. f s = 
.s bind f. 

Two monads cannot in general be composed to form another monad, but the first monad mentioned above 
can in general be composed with any other monad to give a compound monad (see [G. §7.3]). The formulae for 
the extension function, both generally (in terms of units and exts) and for our specific choice of units and exts. 
are given below. In the specific case, extos has type (state -¥ outcome set) -> (outcome set -* outcome set). 

extos f os = extos f os = 

let f (Term ,s) = f s let f (Term s) = / .s 

/' NonTerm = units NonTerm /' NonTerm = {NonTerm} 

in exts f os in U„ 6o , /' « 

As mentioned above, a monad consists of functions unit and ext (of appropriate types), which must 
satisfy certain conditions, as follows: 


ext k o unit = k (Left Unit) 

ext unit = id (Right Unit) 

ext (ext h o k) = ext h o ext k (Assoc) 

Let seq A B denote the sequencing of commands A and B (where A, B and seq A B are of type 
state -> outcome set). As noted, we want, to first apply A to the given state, obtaining a set of outcomes; we 
must then apply the extension of B (of type outcome set -> outcome set) to that set of outcomes. That is, 
seq A B = extos B o A, Then we can prove the associativity of seq thus: 

seq A(seq B C) — extos ( seq B C) o A 

= extos ( extos C o B) o A 

— extos C o extos B o A by the monad rule (Assoc) 

= extos C o seq A B 
= seq ( seq A B) C 

This is proved in Isabelle as seq_assoc. Dunne [1, §7] uses for sequential composition, so he writes seq A B 
as A: B. 
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The unit function, of type stale -+ outcome set of the compound monad is given by 

unit-os s - units (Term .s) = {Term -s } 

This represents the command skip, which always terminates in its initial state. 


3.2 Refinement 

\S we will often just give Isabelle code, we mention some less obvious Isabelle notation The “? indicates 
a variable for which anything (of a suitable type) may be substituted. Some set and funet.on notation 
(mathematical and Isabelle equivalents) follows: 


a & Ui.er & 

{o}U(CUD) C E n F\G 
\x.E 


a UN b:C. D 

insert a (C Un D) < = E Int F 
C/.x- E) 


We define' functions corresponding to wlp, trm , and wp of [1, §2], 


wlpm ?cm ?bm ?state == ALL nst. Term nst : ?cm ?state — > ?bm nst 
trnun ?cm ?state == NonTerm ?cm ?state 

wpm ?cm ?bm 


Here && and 
predicates, so 

?p > ?q 

(?p && ?q) ?s 

(?p II ?q) ?s 


== wlpm ?cm ?bm && trmm ?cm 

lift conjunction and disjunction over states, and — > is the “is stronger" relat ion between 


ALL s. ?p s — > 
?p ?s & ?q ?S 
?p ?s 1 ?q ?s 


These definitions work with commands and conditions as functions of type state -+ outcome set and 
state -4 bool respectively. We note that a command (as such a function) is uniquely determined by its wlp 
and termination conditions. This is proved in Isabelle as unique. Later we will introduce corresponding 
(differently named) functions which take abstract syntax trees as arguments. . . 

In [1. 1)5] Dunne discusses several notions of refinement, including general-, total- 
refinement. The second equivalent definition of gencref is derived from Dunne s (Gcref2) ([2. &2.1J). 


totcref ?Am ?Bm == 
partcref ? Am ?Bm =- 
gencref ?Am ?Bm == 
gencref ?Am ?Bm == 


ALL Qm. wpm ?Am Qm > wpm ?Bm Qm 

ALL Qm. wlpm ?Am Qm > wlpm ?Bm Qm 

partcref ?Am ?Bm & totcref ?Am ?Bm" 
partcref ?Am ?Bm & (trmm ?Am > trmm ?Bm) 

From these definitions, we have derived more direct characterizations of these three notions of refinement 
It is worth noting that the characterization for general correctness is simpler than the other two a though it 
is defined in terms of both of them; this no doubt explains how general correctness semantics often seems 
simpler than either partial or total correctness semantics. 

totcref ?Am ?Bm = (ALL st . ?Bm st <= ?Am st I NonTerm : ?Am st) 
partcref ?Am ?Bm = (ALL st. ?Bm st <= insert NonTerm (?Am st)) 
gencref ?Am ?Bm = (ALL state. ?Bm state <= ?Am state) 


3.3 Meaning of Commands 

„i.jn nerhans magic, abort fl. §7] skip is the command which is feasible, terminates and does nothing 
to the state. It is exactly the function unites. It follows immediately from the (Left Unit) and (Right Unit) 
monad laws that skip is' an identity (left and right) for the binary function seq. These arc proved m Isabelle 

as seq.unitL and seq_unitR. We define 


perhaps ?st == {Term ?st, NonTerm} 

magic ?st == {} 

abort ?st == {NonTerm} 
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preconditioned command [1, §7] The command P\A is the same as A except that, if P does not hold, 
then P\A may fail to terminate. 

precon ?bm ?cm ?state == if ?bm ?state then ?cm ?state else insert NonTerm (?cm ?state) 

guarded command [1, §7] The command P — > A is the same as A if P holds, but is infeasible (the 
outcome set is empty) if P does not hold. 

guard ?bm ?cm Tstate == if 7 bm ?state then ?cm Tstate else {} 

A command has a “natural” guard and precondition. Here f is .4 means A is feasible , that is. its outcome 
set is non-empty. We have proved 

f is_guard = "guard (fis ?Am) ?Am = ?Am" 
pc_trm = "precon (trmm ?Am) ?Am = ?Am" 

choice In [1, §7] Dunne defines a binary operator, ABB, for bounded choice: ABB is a command which 
can choose between two commands A and B. This is a special case of choice among an arbitrary set of 
commands, defined by 

choice C s= |^J c s choice ?cms ?state == UN cm:?cms. cm ?state 

rec 

From these, we prove the definitions, and some other results, of Dunne. 

perhaps.alt = "perhaps = precon ( 9 /,st. False) unitos" 
magic_alt = "magic = guard ( # /,st. False) ?A" 

abort_alt = "abort = precon (%st. False) (guard ( # /,st. False) ?A)" 

pma = "seq perhaps magic = abort" 

asp = "choice {abort, unitos} = perhaps" 


concert [1, §12] The command A#B represents .4 and B executing independently, on seperate copies of 
the state: whichever of .4 or B terminates first gives the effect of A#Z?. Thus the possible outcomes of A # B 
are: 


- Term .s, if it is an outcome of A, 

- Term s, if it is an outcome of B , 

- NonTerm, if it is an outcome of both A and B. 

cone ?Am ?Bm ?state == concrs (?Am ?state) (?Bm ?state) 

concrs ?crl ?cr2 == ?crl Un ?cr2 - {NonTerm} Un {NonTerm} Int ?crl Int ?cr2 

Interestingly, this means that if B is magic (everywhere infeasible), then A#B is just A with any possibility 
of non-termination removed (difficult though it is to see from the first sentence above!). This is proved in 
Isabelle as conc_magic. 

The wlp and termination conditions for these commands, which are used by Dunne to define, these com- 
mands. are proved in Isabelle from our definitions, as precon_trm. precon.wlp, guard_trm, guard_wlp, 
seq_trm, seq_wlp, choice_trm, choice_wlp, conc_trm and conc_wlp. Dunne’s results Xpre. Xguard, Xas- 
sump and Xassert are also proved in Isabelle, under the same names. 

3.4 Repetition and Iteration 

finite repetition [1, §7] Dunne defines A 0 = skip and A ri_M = A; A". A very convenient result which we 
proved, called rep_Suc J , is that A M+1 — A n ;A. 
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repetitive closure [1, §12] Wo also defined repall r h = U„ rv P » <’ *- »'• 
repall ?cm ?state == UN n. rep n ?cm ?state 

that is, repall ,4 is the (unbounded) choice of any number of repetitions of .4. The termination condition 
for repall .4 is that for every n. .4" terminates (proved as repall.term). 

The repetitive closure, of .4 is .4* . where the outcomes of .4* are those of repall, augmented bv NonTerm lit 
the case where it is feasible to execute .4 infinitely many times sequentially (we call this an "infinite chain ) 
It is considerably easier to define this concept operationally than in terms of wlp and trm. The definition o 
this circumstance asserts an infinite sequence of states, of which each is reachable from the previous one. We 
omit the Isabelle definition. 

infr.h .4 a = 3/. / 0 = .s A (Vn. Term (/ {n + 1)) G A (/ n)) 


Thus we have 1 the definition 

repstar ?cm ?state == repall ?cm ?state Un (if infeh ?cm ?state then {NonTerm} else {}) 

It may be noted that in [1, §10]. Dunne defined a predicate etc ("cycles and infinite chains"), with the 
intended meaning (in effect) that civ. .4 « be true if .4, executed it, state .s, might not terminate. However 
the definition made etc. A s true in the situation where .4 could be executed any given n times sequentially, 
which is not sufficient to ensure an infinite chain of executions. (It would he sufficient under an assumption 
of bounded non-determinacy. see [4, §3]). As is a common experience, we did not discover this discrepancy 
until trying to perform Isabelle proofs based on the definition in question. 

We have proved some useful results, such as 

wlpca : wlp(A*) = wlplTepa.HA) (since they differ only in that .4* has an additional possibility of noil- 
termination) 

seq_repstar : .4*;. 4 = .4; .4* 


§ 6 ]- 


In [1. §12] Dunne mentions that repetitive closure could be defined using Egh- Milner approximation [1, 


.4 <, m .4' he .4 C lol .4' A .4' C,,« r .4 

where Q tol and C par denote respectively total- and partial-correctness refinement. Then .4* is a least fixpoint 
under the ordering < em : 

.4* =p em X.(A-,X)askip 

We show in Isabelle that our definition of .4* implies this result. Here fprep_alt2 is a paraphrase of our 
definition of fprep (fprep ,4 X means A' = (A; X)Oskip), repstar.isfp says that .4* is a fixpoint and 
repstar. is.lfp says that .4* is less than or equal to, in the Egli-Milner ordering, any given fixpoint 1 . 

fprep_alt2 = "fprep ?Am ?Xm = (?Xm = choice {seq ?Am ?Xm, unitos})" 
repstar.isfp = "fprep ?Am (repstar ?Am)" 

repstar. is. If p = "fprep ?Am ?Ym ==> egMil (repstar ?Am) ?Ym" 

Dunne (personal communication) also defines trm{ .4 * ) and wlp(A .Q) as fixpoint.s. 


trm(A*) = vY.wp(A.Y) 
wlp{A" . Q) = pY.wlp(A, V ) A Q 

where p and »/ denote the leasl and greatest fixpoints, that, is the weakest and strongest (respectively) 

fixpoints. We also prove these results in Isabelle, based on our definition of .4’. trfp and wrfp say that 

trrn(A*) and wlp(A*.Q) are fixpoints of the respective functions, trsfp says that trm(A*) is equal or weaker 
than any given fixpoint V, and similarly for wrwfp. 

trfp = "let trmstar = trmm (repstar ?Am) in trmstar = wpm ?Am trmstar 
trsfp = "?Y = wpm ?Am ?Y ==> trmm (repstar ?Am) > ?Y" 

wrfp = "let wlpstar = wlpm (repstar ?Am) ?Qm in wlpstar = (wlpm ?Am wlpstar && ?Qm) 

wrwfp = "?Y = (wlpm ?Am ?Y kk ?Qm) ==> ?Y — - > wlpm (repstar ?Am) ?Qm" 
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3.5 Monotonicity 

For developing a program by starting with an abstract expression (of requirements), and progressively refining 
it to a concrete program, it is important that the abstract commands constructors are monotonic with respect 
to general-correctness refinement 

Given our characterization of .4 Q gen D as (V state. B state C .4 state), and our operational definition of 
commands in terms of their outcome sets, it is easy to see that all the constructors mentioned are monotonic. 
In any event, they are proved in Isabelle as (for example) seq_ref _mono. rep_ref _mono, repstar^ref _mono. 


3.6 The while loop 

In [1, §7, §12] Duma 1 defines 


if G then A end = (G — > A)D(~*G -» skip) 
while G do A end = (G -> ,4)*; -iG -> skip 

The definition of while which is intuitive to programmers is 

while G do .4 end = if G then A: while G do .4 end end 

We cannot use this as a definition in Isabelle since it is recursive as it stands it is non-terminating, and 
when applied to a particular state, may not terminate. So in Isabelle we have defined while as dot's Dunne, 
and have proved that it, satisfies the “intuitive” definition. 

while_prog = "while ?G ?A = if then ?G (seq ?A (while ?G ?A)) M 

4 Frames and Variable Names 

In §3, we viewed a (command as a function from a state to a set of outcomes, and a condition as a predicate 
on states. In this treatment, the view of a state was abstract. As discussed in §2, there are various ways in 
which a full treatment needs to be more concrete, namely 

- referring to program variables 

- having conditions in a form in which we can substitute for a program variable 

- specifying a frame for a command 

In this section we discuss those abstract command constructors which require us to address these issues. 

In our Isabelle model, the program variable names are strings and they take natural number values. As 
a state is an assignment of variables to values, we have the type definition state = "string => nat" 


indeterminate assignment [1, §12] Where x is a (list of) variables, and P is a predicate, the command 
x : P assigns values to the variable(s) in x in any way such that the change of state satisfies P. More precisely, 
if a is the '"current alphabet” (the set of variables whose names are currently “in scope”), and r () is the set 
of variable names in x, but with subscript 0 added, then P is a predicate on a U x 0 . (The paper [1] says 
a U Qo - we comment on this below). The subscripted variable names represent, the values of those variables 
before the command is executed. We model such a P as a function on two states, so our definition of this 
command is 

indetass ?vars ?P ?s == Term ‘ (Collect (?P ?s) Int chst ?vars ?s) 

where chst ?vars ?s means the set of states which differ from ?s only in the variables ?vars. f ‘ X means 
{/ x | x € A’’}, and Collect (?P ?s) means {s' | P s s'}. 
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prd [1. $10] The “before-after" predicate prd specifies conditions under which the command may terminate 
in a state where variables have certain given values. Dunne defines this as 

prd (.4) = ->wlp (A.x ^ ./■') 

when 1 x* are new (logical) variables corresponding to the program variables. We define prds and prdm. as 

prds ?strs Tdashed ?Am == Not o wlpm ?Am (/»st. EX str: Tstrs. st str — ?dashed str) 
prdm ?dashed ?Am == Not o wlpm ?Am C/,st . st “= ?dashed) 

where ?dashed. of type state, represents the values x f . and prdm is a simpler version of prds for us(' when 
x can be taken to be all variable names. As a sort of inverse 1 to this definition. Dunne give’s wlp {A.Q) = 
Vx' .prd (.4) => Q[x := x'] which we 1 prove as 

wlp_prd = "wlpm ?Am ?Qm ?state = (ALL dashed, prdm dashed ?Am ?state — > ?Qm dashed)" 

In [2. $9] Dunne states the result prd (x : P) = P[x 0 ,x := x,x'}. We 1 proved a corresponding result for 
the special case where x represents all variable names 

indetass_prd = "prdm ?dashed (indetass UNIV ?P) ?state = ?P ?state ?dashed" 

but found that we could not prove 1 the stated result generally. It turned out that Dunne's result requires 
that P be a predicate on a U x 0 . not on a U a 0 (as stated in the paper). This is another example of the 
common situation that attempting to prove such results formally detects [joints such as this which can easily 
be overlooked in an informal treatment. 

unbounded choice [1, §7] The command (@2-4) means that variable z is to be set to an\ value and then .4 
is to be executed. But 2 is to be a “local” variable in A: if, for example, Q contains 2 . then it is a different z 
from that in A. In other words, the notation correctly reflects that 2 behaves as normal for a bound variable 
(it can be a-converted with no change in meaning). 

So we model this command as follows: 

- set variables 2 to arbitrary values 

- execute A 

- reset variables 2 to their initial values 

setstrs ?strs ?strfun ?state ?str == if ?str : ?strs then Tstrfun ?str else ?state ?str 
revert ?strs ?Am ?initst == mapos (setstrs ?strs Tinitst) (?Am Tinitst) 
at ?strs ?Am ?initst == 

let initptf = 7,strfun. setstrs ?strs strfun Tinitst; 

initptc = 7.x. UNION UNIV (?Am o initptf) 
in revert ?strs initptc Tinitst 

Here. UNION UNIV F = {J V F x. and mapos is the monadic “map” function: 

mapos f ocset = {mapo f s | ,s E ocset) 
mapo f (Term s) = Term (/ ,s) 
mapo f NonTerm = NonTerm 


\\v then provtxl 

at_trm = "trmm (at Tstrs TAm) = allstrs Tstrs (trmm TAm)" 

where allstrs strs D ,s means that for any other state s’ obtained by taking s and setting the variables 
strs to any values, D s’ holds. We tried to prove 

wlpm (at ?strs ?Am) ?Qm = allstrs ?strs (wlpm ?Am ?Qm) 
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but could not. This reflected the fact that the formula for wlp ( ^z.A) given by Dunne assumes that Q does 
not involve z. (As noted above, the a-convertibility of 2 in <xz.A means that we can sensibly assume this). 
In fact we proved 

at_wlp = "indep ?strs ?Qm ==> wlpm (at ?strs ?Am) ?Qm = allstrs ?strs (wlpm ?Am ?Qm) 

where indep z Q means that Q is “independent” of 2 . As Q is a semantic expression, not a syntactic* one 
(see §4.1), "independent” was defined to mean that changing t does not change Q. 

4.1 Assignment; the Syntactic View 

As noted in §2, wlp(x E.Q) = Q[x E], which is only meaningful when Q is some structure in which we 
can define substitutions. So we have defined types for the abstract-synt ax- tree version of integer and boolean 
expressions, thus (abbreviated): 

datatype exp = Num nat 

I Var string 
I Pluss exp exp 
I Minus exp exp 
I Timess exp exp 

datatype bexp = Eq exp exp 
I Lt exp exp 
I Le exp exp 
I Gt exp exp 
I Ge exp exp 
I Nott bexp 
I T 
I F 

I And bexp bexp 
I Or bexp bexp 
| Imp bexp bexp 

We defined substitution functions, of the following types 

expSub : : "string => exp => exp => exp" 

bexpSub : : "string => exp => bexp => bexp" 

where (for example) expSub x E M means M[x := E]. We also defined functions to translate an expression 
(type exp or bexp which we will call a syntactic expression) to the corresponding function of type state — > 
nat or state — > bool (which we will call a semantic expression). We may also say the semantic expression 
is the "meaning” of the syntactic expression. Obviously, distinct syntactic expressions may have the same 
meaning, and therefore the i4 =” symbol in a proposition of the form "wlp {A,Q) = . . .” can only be sensibly 
interpreted as equality of semantic expressions, notwithstanding that in “wlp(x := E Q) — Q[x := 
the right-hand side is only meaningful as a syntactic expression. We can talk about syntactic and semantic 
commands also. 

types 

expMeaning = "state => nat" 
bexpMeaning = "state => bool" 

consts 

expMng : : "exp => expMeaning" 
bexpMng : : "bexp => bexpMeaning" 

We can then prove the following results, and corresponding ones for boolean expressions. 
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subLemma = "expMng (expSub ?x ?E ?Q) ?state = expMng ?Q (?state(?x expMng ?E ?state))" 
sub_equiv = "expMng ?Q = expMng ?R — > expMng (expSub ?x ?E ?Q) - expMng (expSub ?x ?E .R) 


Here /(x := E) is Isabelle notation for the function that is like / except that its value at argument x is E. 
The first of these results relates substitution for a variable in an expression to assignment to that variable 
in the state. The second expresses that if two syntactic expressions have the same meaning, then the results 
of making the saint' substitution in the two of them also have the same meaning. (Thanks to Dunne foi 
pointing out the need for this result). 

We are now in a position to define assignment and prove its properties. We define ass ignv and assigne 
for the assignment , to a variable, of a value and a (semantic) expression respectively. Wo also define assignvs 
for the assignment of values to a set of variables. 


ass ignv ?var ?n ?state == {Term (?state(?var := ?n))> 

assigne ?var ?E ?state == assignv ?var (?E ?state) ?state 

assignvs Tstrs ?strfun ?state == {Term (setstrs ?strs Tstrfun ?state)> 

We can then prove ass_trm (which is trivial an assignment terminates), and ass.wlp. which says wlp(:r 
E,Q) = Q[x := E}. 

ass_wlp = "wlpm (assigne ?x (expMng ?E)) (bexpMng ?Q) = bexpMng (bexpSub ?x ?E ?Q)" 


4.2 Normal Form 

In [2, §7.1] Dunne gives the following result., giving a “normal form" for an abstract, command .4. 

.4 = trm (.4) | fix' .prd (.4) — >■ x := x' 

Here x is the frame of .4 (which we first take to be the entire current alphabet of variable names), and x' 
is a corresponding set of logical variables, with names dashed. For this purpose we want somewhat different 
definitions of ®t and of .4. involving a set of logical variables x', one for each program variable. So we use a 
function dashed, of type state, which gives the values of these logical variables. 

atd ?Ad ?state == UN dashed. ?Ad dashed ?state 

Here ?Ad is not a semantic command, but a function which, given a “dashed state as argument, returns 
a semantic command. Then also the assignment x := x' (where x represents all variables) becomes the 
replacing of state x by “state" x\ Thus we prove the following corresponding result . 

ACNF = "?A = precon (trmm ?A) 

(atd ( # / 0 dashed. guard (prdm dashed ?A) (*/,st . {Term dashed})))" 

We also proved a corresponding result for the case where x is a proper subset of all variables. Hen' Dunne's 
result requires that ,4 does not change variables outside the set x. Rather than specify this requirement as 
such, we proved a result whose left-hand-side means “A restricted to x", that is, as though you executed .4 
and then reset the variables outside x to their original values. 

ACNFs = "revert (- ?x) ?A = precon (trmm ?A) 

(atd ( # /*dashed. guard (prds ?x dashed ?A) (assignvs ?x dashed ))) 1 


4.3 Frames 

In Dunne's formulation [1, §7], each abstract command comes decorated with a frame, and the frame of the 
new command is defined individually for each abstract command constructor, for example 

frame (.-!□£) = frame (A#B) = frame(A) U frame{B) 

However we are unable to give an exact semantic meaning to the frame in a similar sense to the meaning we 
have given to commands so far. The frame may be thought of as a set of variables “potentially set by the 


46 


.leremv E. Dawson 


commands, but it can be larger than the set of variables actually set by the command. The frame may be 
smaller than the set of variables read by the command, and two commands which have the same semantic 
meaning can have different frames. Accordingly we could not attempt to prove the statements about frames 
given by Dunne in the definitions of abstract commands from our operational model, in the way we have 
done for their wlp and trm conditions. The best one could do is to attempt to prove that for any abstract 
command the frame of the result contains the set of variables which are changed by the command. However 
this does not look at all difficult in any case, and so we have not included frames in our model. 


parallel composition [1, §12] This is the only abstract command operator whose meaning depends on the 
frames of its operands. The command .4||i? executes A and B , independently, each on its own copv of the 
variables in its frame, and waits until both have terminated. (Thus, non-termination is a possible 1 outcome of 
A\\B if it is possible 1 for either .4 or B). We sav a new state resulting from .4 is compatible with a new state 
resulting from B if these new states agree on the values they give to the variables in fmme{A) Dframe(B). 
Then, for each (a\i,.s/*), where s \ and .s/j are compatible new states resulting from .4 and B respectively, 
there is an outcome Term s\B of A\\B, where ,s ah is given by: 

- the new values of variables in framc(A) D frmne(B) are as in (or s fi ). 

- the new values of variables in frame{A)\framc(B) are as in and 

- the new values of variables in frarne(B)\framc(A) are as in ,s B . 

Dunne defines A\\B by 

trm(A\\B) = trm(A) A trm(B) 
prd(A\\B) = prd(A) A prd(B) 

but the latter formula contains an implicit reference to the frames of the commands. It is interesting to note 
that if .4 is infeasible, and B is feasible but does not terminate, then .4||Z? is feasible but does not terminate. 

We consider first a version of this command for which the frame is the entire set of variables, defined by 
pcomp_def and pcomprs_def ; for these, we prove the formulae? just mentioned, as pcomp_prd and pcomp_trm. 
We also prove as, pcomp_wlp, a result (communicated by Dunne) 

wlp (A\\B) Q s = 3Q i Q 2 -(Vt.Q\ t A Q 2 t, => Q t) A wlp(A,Q x ) s A wlp(B< Q 2 ) s 

Unusually, we have explicitly referred to states & and t in this statement, of the result to make it. clear that 
the choice of Q\ and Q 2 elepends on the state s. 

The following definition of A\\B takes into account the? frames of .4 and B. Firstly, pccomb combines two 
states (resulting from ,4 and B) if they are compatible. 

"pccomb ?frA ?frB ?initst (?stA, ?stB) = 

(let compat = ALL str:?frA Int ?frB. ?stA str = ?stB str; 
comb st = 7,str. 

if str : ?frA then ?stA str 

else if str : ?frB then ?stB str else ?initst str 
in if compat then {Term combst} else {})" 

"pcompfr ?frA ?A ?frB ?B ?state == 

let tsA = {st. Term st : ?A ?state}; 
tsB = {st. Term st : ?B ?state}; 
nont = {NonTerm} Int (?A ?state Un ?B ?state) 
in nont Un UNION (tsA <*> tsB) (pccomb ?frA ?frB ?state) " 

Here (tsA <*> tsB) means the set product of tsA and tsB. The result pcomp.chk is a sanity check that, 
where the frames of A and B are the set of all strings, this definition is equivalent to the one mentioned 
in the previous paragraph (a useful check, since our first attempt at the definition above was erroneous). 
Noting that Dunne’s formula prd(A\\B) = prd(A) A prd(B) implicitly refers to the frames of the commands, 
we prove it as pcompf r_prd, as follows: 

pcompf r_prd = "prds (?fA Un ?fB) ?dashed (pcompfr ?fA ?Am ?fB ?Bm) = 

(prds ?f A ?dashed ?Am && prds ?fB ?dashed ?Bm) " 
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5 Conclusion 

Wo have provided an operational model for Dunne's abstract commands and their operators, except that 
our model does not provide any information about the frame of a command. Based upon tins model, we 
have been able to prove, using the automated proven Isabelle. Dunne s definitions of the abstract command 
operators, except their frames. That is, we have shown that they follow from our operational model. 

We have discussed the problems in including the frame of a command in this work. Briefly, while the 
frame of a command might be thought of as the set of variables which “might” be set by the command, 
commands such as x := x (whose frame is {*}) prevent us from defining the command's frame from its 
behaviour. We could have attempted to show that the frame of a command (as defined by Dunne) conforms 
to a rule that the frame contains any variable which can be changed by the command, but this generally 
seems obvious. 

Formalising the various definitions for use in the mechanised prover lias highlighted aspects of the spec- 
ification of commands which need to be considered, but are easily overlooked until one formalises them. 
Examples of this appear in our discussions about “syntactic" and “semantic” expressions and commands, 
and about the language in which “syntactic expressions may he expressed. 


Acknowledgement. We wish to thank Steve Dunne for his very great assistance in some lengthy discussions 
on the topic. 
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Abstract. Earlier papers have described how lax logic can be used to develop verified designs, where 
the lax logic modality is taken to represent some constraint,. We show how to use Isabelle’s instantiation 
of variables to obtain elegant proofs of results which are true subject to constraints, and to derive these 
constraints. We show how this met, hot! ran be applied to examples of hardware design (where 1 the 
constraints relate to timing) and to a numerical function (where the constraint is that the machine 
word length is sufficient). 

The Isabelle files required to run the examples in this paper may be found in 
http : / / www . dcs . shef . ac . uk/~matt/lax/isabelle/Public 

Keywords: lax logic, machine-checked proof, hardware timing 


1 Introduction 

In [7] Mendler describes Lax Logic and how its single modality may be used to represent that a condition 
is true up to satisfaction of some constraint. He gives examples, including the calculation of the factorial 
function using increment and multiplication, which are themselves accurate only up to a constraint. In the 
factorial example, he takes the constraints on these to be that the word length of the computer is sufficient. 
In [4] Fairtlough. Mendler and Cheng have described how to analyse the behaviour of hardware, where each 
particular predicate on the state is true only at certain times, so the constraint is that the predicate is 
considered at the “right” time. They note that the proof of the “logical” result (e.g, for an and-gate, that 
if the inputs are true then the output is true) can be separated from the timing constraint (that the inputs 
have remained true over a certain time interval), and suggest that the proof algorithm could actually be 
used to calculate the constraint. They go on to describe some examples. 

In this paper we flesh out this suggestion and consider some examples, including the “latch” example of 
[4] and the "factorial” example of [7]. We show how we can perform an Isabelle proof in the usual way. but 
with the constraint initially being a variable, which gets instantiated during the course of the proof. In this 
way the constraint is generated by the prover which also proves it correct, in the sense that it implies the 
corresponding predicate. 

Such calculated constraints are not in their simplest form. In Section 3.1 we describe some conversions 
written to help simplify the constraint which was calculated for the “latch” example, which we expect would 
be useful for other automatically generated timing constraints. 


1.1 Lax Logic 

In [3] Fairtlough and Mendler develop “Lax Logic” 1 . This is described as an intuitionistic modal logic*, with 
a single modality O, which obeys the following axioms: 

OR : M D OM 
O M : CO M D OM 

OF : (M D N) D (OM D OA r ) 

this work was supported by EPSRC under grant GR/L86180 
1 The logic has been independently invented bv Curry [2] and Benton, Biorman k de Paiva [1] 
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() nP interpretation of the modality O is that it denotes an anonymous constraint or qualification of some 
sort, that is. O M means that M holds under some (unspecified) constraint, or qualification. For example, 
the constraint may be that a certain condition C holds, so OM is C D M , but C is not made explicit. 

Tin' latter two axioms may he replaced by the single axiom O E. and uS and O C aie also useful. 


O E : (M D ON) O (O M D ON) 

OS : (OM A ON) D O (M A N) 
o c : (M 0 ON) D(LO OM) D (L D ON) 


Lax Logic can he expressed in a Gentzen-style calculus, with the usual singletons-on-the-right restriction 
from the Gentzen calculi for Intuit ionistic Logic, with the following rules for O : 


r I- m 

T h DM 


(h o) 


r. m f o.v 


r. OM b ON 


T(Ob) 


The O modality is unusual as it has some properties which are typically □-like and others that are typically 
O-like. The usual explanation of this, that DA e— ► 0.4 when the underlying Kripke relation R is functional, 
does not hold in Lax Logic (where .4 < — 4 B stands for (.4 D B) A (B D .4)). 

Lax Logic also has a Natural Deduction formulation, which we shall use in the rest of this paper. Its 
rules for O appear in Table 2. This formulation is equivalent, under the Curry-Howard correspondence to the 
typing rules for simply-typed A-calculus with a strong monad [9] an extension of Moggi s computational 
A-calculus. The constraint computations carried out in the examples of this paper use the computational 
rules for the set monad, which are of course consistent with the general equations for a strong monad. We 
stress this point because our method relies on the extraction of constraint information from an abstract 
proof; this extraction process involves the abstract computational rules of t.he calculus, the specific rules of 
the set monad and the higher-order logic rules for equivalence between propositions. From this viewpoint 
it. is no surprise that the way in which abstract formulas are proved determines the constraints that are 
extracted from their proofs. 


2 Abstract and concrete formulae 

In [4] Fairtlough, Mendler and Cheng use Lax Logic to separate aspects of reasoning about hardware circuitry. 
At the concrete level, aspects such as timing must be' taken into account, whereas at, the abstract level, only 
a simplified “boolean” description of the behaviour of devices suffices. For example, at the abstract level, we 
have “if inputs P and Q are true (high) then output R is also true”. Correspondingly, at the concrete level, 
we have “if inputs P and Q are both high at time t, and remain high until time t + &i , then output R goes 
high no later than t + 6 2 , and remains high so long as both P and Q remain high . 

Henceforth, following [4], we work in higher-order logic (HOL), and we will define a function O v which 
satisfies the Lax Logic rules for O. This function is in fact the set monad. Other monads undoubtedly also 
have their uses within our framework, but we have not yet explored them in any detail. The literature on 
combining monads, see for example [6], provides a rich source of ideas for extending our method. 

Following HOL convention, we will write implication as -t, and following the usage of the Isabelle theorem 
prover, we will use P => Q to denote the meta-proposition “Q can be deduced from P" (for which we also 
use the conventional horizontal bar). Also following Isabelle, we use “!!” as a universal quantifier understood 
at the meta-level. 

2.1 Translating logic into the concrete/abstract format 

Consider as an example a concrete formula such as P a, which means that signal P is high (true) at time .s, 
and likewise a second formula Q t. The corresponding abstract formulae are just P and Q, whose conjunction 
is P A Q. The concrete formula expressing the conjuction is P n Q. defined by (P n Q)(s. t) = PnAQ t. 

More typically we would want to express a formula containing an arbitrary constraint, for example 
V.s.s Here one could separate the concrete and abstract by writing {s|s > 5} C {s\P .s}. We 

define the concrete modality O v by OyPc = Vs.cs -t P s; then C v obeys the Lax Logic axioms for O given 
earlier. We can now write this last constraint as OyP(As.s > 5). 
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In both these' expressions, i.e. (P \1 Q)(x, t) and OyP(A,s.,s > 5). the concrete part is the (last curried) 
argument, and the abstract part is the rest. 

Note, however, that in the latter example, the abstract part includes the Lax Logic modality o v . 

2.2 The translation used in the Isabelle/HOL implementation 

As an alternative to the* above, we tried replacing predicates by the corresponding sets (where the predicate 
is the characteristic function of the set), replacing P s by ,s € P, and so forth. After experimenting with both 
styles in Isabelle/HOL, we proceeded with the set-based implementation, since it renders the derivations of 
the rules corresponding to OP. OA/, OP, OP and 05 particularly transparent (these are given later, in 
Table 2). 

In the set-based notation, the definition of n becomes (.s, /) E (P n Q) = s E P A t E Q and the formula 
V.s.,s > 5 -> .s E P is rewritten as {,s | .s > 5} E OyP , where r E O v P = V.s*..s E r s E P. This last definition 
may be more simply written r E OyP = cCP. 

Thus, in this formulation, the concrete formula is of the form r E P, where the abstract formula is 
simply P. Henceforth in this paper, we will follow our Isabelle implementation and write formulae using the 
set-based formulation rather the function-based one. 

2.3 Calculating constraints 

Intuitively, the formula s E P may be seen in the light that s is a concrete witness of the abstract formula 
P; it gives an instance when 1 P holds. Likewise, in the formula (,s\ t) E (PnQ), (,s\ t) gives an instance when 1 
png holds. 

In reasoning about timing of logical circuits, when P and Q are “primitive” (eg gate inputs or outputs), 
,s and t will be of type “time”. Note, however, that the witnesses for “compound” (abstract) formulae 1 , such 
as Png, will be of a different type. For example, {sj) is of type “pair of times”. 

As noted above, the abstract formula PAQ corresponds to the concrete formula (.s\ /) E (PnQ). Likewise, 
the following two (Natural Deduction style) rules of inference (of which the second is expressed in two forms) 
correspond. 

P Q s € P t E Q fst :EP snd z E Q 

P a Q (M) e (Png) :E (P n Q) 

Note here that the rule calculates the witness for the conclusion from the witnesses for the premises. 
Alternatively, if the rule is used in a backward proof, the second form calculates the required witnesses for 
the two subgoals in terms of the required witness for the conclusion. 

Similarly, we can find a concrete equivalent for all the rules of Lax Logic. Table I gives many examples 
for the intuitionistic logic rules. In some cases the rules are in the specific form used in the Isabelle/HOL 
system. The third column gives the name of the rule (or of a close equivalent) in the implementation. 

Note that, because a concrete formula specifies a witness, a simpler rule than Sumd_Ep is available for 
eliminating an abstraction namely the inverse of the SumcLIp rule. 

For the rules using the Oy operator, a selection of the rules is shown in Table 2. Note that the rules 
labelled (OyP). (OyA/), etc, are equivalent to the axioms (OP), (OA/). etc listed earlier, but they are in the 
form of Natural Deduction inference rules. Note that, the binary infix operator 4 (written op 4 as a curried 
2-argument function) is given by op 4 fS = / ; 5 = {fx | x E 5}. 

2.4 The “Tiny” example 

In [4] the following simple example is given. The concrete formulae (expressed in terms of sets rather than 
predicates) are 

i'l : V.s.s > 5 — ► .s E Pi a 
ii '2 : V.s y.s > 9 y — > ,s E P'i(fy) 

: Vtsih V'iXt > -s + 35 A s E Pvih A s E P 2 y 2 ) -> t E Q(g{yi , y 2 )) 
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Table 1. Some logical rules with concrete equivalents (Natural Deduction format) 


Abstract 


Concrete 


HOL rule 


/ ’ AQ 

p=>g 


R 


(A/) 

(-+/> 


R 

P Q 
PAQ 

p =» g 
p -> g 

p->_g_p 

g 

p->g g 

P -r /? 
Vy.Py 


-(A E) 


E) 

R 


Px 

Wx.Px 

Vtj.Pt/ 

Px 

ByPy 


(VE) 

(V/) 

(3/) 


3 y.Py Wx.Px 

7? 


■(BE) 


xePnQ 

fst x 6 P - 


snd x € g 


/? 


R 

.s € P teg 

(M) € (Png) 

!!*.* e p =*• /* e g 


-(n£) 


(n/) 
(□/) 


-(□ £) 


/ € p □ g 

/ € P □ g v € p 
/peg 
/ 6 p n g ?/ 6 g n p 

g o f e P 3 R 

/ e n u-Py 

fx e Px 
W.x.fx G P.t 

/ i nw-Ptf 

2 e Pw 


(u 1 , z) e U?/-Py 
(ti/,2) e LJy-Py 

Wux.u e Px => /xu e R 
fwz € P 


andd_Es 
andd^I 
impd_Ip * 
impd_Ep’ 
impd_trans 
Prodd_Ep 
Prodd_Ip 
Sumd_Ip 

Sumd_Ep 


Firstly, these are rewritten to use CV 

t/'f : {.s > 5} G Ov(Pi«) 

4 : Vt/.j.s > 9»} € o AP-Afy)) 

4 : Vt/ l2 /2-si-s-2-si e Prn A .s, € P>y> -4 \t | *1 = *•> A f > .s, + 35} € Ov(Q(g(yi ■ *fe))) 

From the above we can delete the concrete information (i.e, that before E. and the quantified variables 
#, and s 2 ) to get the following formulae which are abstract, but, expressed in terms of Lax Logic. 

tf : Ov(Pta) 

V’., 2 : Vty.Ov (/Id/.'/)) 

cfj 2 : Vt/ij/ 2 -Xij/i A P>y> -4 Ov(Q(g(yi,y- 2 ))) 

Where it is required to prove 3t-.Ov(Qv), the abstract. Lax Logic proof would run as follow s. 

ll>2 

l/.'-j V >1 Vy.Ov(P i(fy)) 

Vy\y-2-P\V\ a P-i y-i -> Q\/(Q(g(yi ■ y-j))) Qv(Pi«) Oy(p2(/h)) (q v 5) 

Pi o A P>(fb) -»Oy (Q(fl(a, /ft))) O v (P|n A P 2 (fb)) ^ £ ^ 

Oy(g(.9(Qr /ft))) 

3v.Ov(Qw) 

Note that we use (O v S) and (OyP) for rules which are equivalent to the corresponding axioms shown in 
§ 1 . 1 . 

To do the concrete constraint calculation, we would rewrite the formulae again using the logic of the 
implementation such that the abstract formulae appear after the 6, as follows (we also show an intermediate 
step in the rewriting for i>:s): 
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Table 2. Some modal rules with concrete equivalents 


Abstract 


Concrete 


HOL rule 


P 

Oy P 

P -+Q 


(Ovi?) 
(OyF) 


O yQ 


x e p 

{x} € OyF 

/ € P □ Q 

op ‘ / E Oy P □ OyQ 


Dall.unit * 


Dall_F_image 


0v(0 yP). 


OyP 


(O V M) 


OyP OvQ 
Ov(P A Q) 


(O v S) 


S € 0v(0 yP) 

U5 € O v P 
S G O v P T G O v Q 
S x r € Ov(Png) 


Oall_M_Union 


Oall_S_times 


P OvQ 

OvQ 


OwP 

-^-(Oy£) 


f e P 3 OvQ S G OvP 
U(/‘5) G OvQ 


Oall^ext 5 J 


t’l : {.s > 5} C Ov(Pi«) 

: Ay.{.s > 9y} c n:v-Ov(^L>(/y/)) 

(intermediate form) : 

Vyi V2’^( s i i >s 2 ) • { f | #i — #2 A f > a*i + 35 } € P i tji A P 2 y 2 (</(// 1 - yj ) ) ) 

Pi • Ay i y -j . A (.s i . ,s*-j ).{t | ,S| = ,s*> A / > .s*i -f 35 } C n yi jji-P \y\ A P 2 y 2 — > Ov(C?(f/(.Vi 7 2/2))) 

We would then repeat the proof, using rules on the right-hand sides of Tables 1 and 2 . In the implemen- 
tation in Isabelle/HOL, we use the rules listed in place of the logic rules. The file Tiny 2 .ML gives a proof 
of the goal p : \J v.O^(Qv), for some appropriate p, which precisely mimics the abstract proof above, using 
the corresponding rules shown in the Tables. In Isabelle we can leave p unspecified it is a variable in the 
goal and the proof process in Isabelle calculates it. by instantiating the variable. 


2.5 The “Latch” example 

This example deals with a latch, with two inputs r jn and s iu , and two outputs q ouf and Tp^j. The latch is 
constructed using two cross-coupled NOR-gates, and has the “memory v property that, 

- if one input is low and remains so, and 

- the other input is high and goes low, 

- then (so long as both inputs remain low) the outputs remain the same as they were when one input was 
high. 

This is possible because of the feedback from each gate to the other in the design of the latch circuit, and 
because the gates have a finite delay. 

The rules governing the latch, as relevant for this proof, are 6\, 0 2 and and the initial conditions are 
Q p i arid 0 p2 . The notation (s a7 t a ) £ (]r* n D means that, for all times from s a to t a inclusive, the signal r tn is 
high. It may be noted (from the description above of the latch functionality) that the outputs should remain 
steady regardless of whether or when r in goes low (in fact the outputs q out and q^i should remain low and 
high respectively). 

Qpi • £ (]Dn[) 

e p2 : v< > s a .{s a ,t) e dl«»nD 2 

0\ : V.s t.(s, t) € O r mD ( s + d\,t + Di ) G dlVoutD 
62 : V.s 1 ti s 2 t 2 .{suti) 6 dl«.»D A (*’2, h) G dlVoutD -> 

(max si S'j + d 2 , min t, 1 1 2 + D>) G d^oufD 


2 ] is used for not. as in [4], 
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: V.s t.(. s. f ) G D — > (.s + d\ , t 4* D \ ) G fllf/oii/D 

\\V translate these into the form which separates the abstract, and concrete to get 

0 P i : M a ) G (|r in D 

fl p2 : > *4 € Ov(|l«i„D 

0\ : A(.s, /).(.s 4- d \ , t + ) G (]r,„ D □ dl</rmf D 

0,> : A((.s*i , t \ ), (.s‘ 2 , ^))*( max * s i • s - ) + /■? + ^ 2 ) G dl D ^ dl^»«/D T1 

0^ : A(.s. + d\ ,t + D\ ) G dfloiw D Tl 01</<>wf D 

The reasoning goes like this: 

(a) Because r in is high (by 0„i), q 0 ut is low (by 0 1 ). 

(b) Because ,s in is low (by 0 P 2 ) and </ ou / is low (bv step (a) or (c)), q ou t is high (by # 2 )- 

(c) Because ^7 is high (by step (b)), q ou t is low (by 0 3 )- 

(d) Now go back to step (b) 

B ('cause of the inertiality and delay of gates, this cyclic argument corresponds to the physical process 
that keeps q out low permanently. Note that it, requires that s in be low permanently, which is expressed by 
the concrete version of 0 P 2 - 

The proof can be broken into three parts: step (a), steps (b) (c) (d), and the integration of these two 

parts. We first discuss steps (b) (e) (d). 

The abstract result we prove is dl<wD =» °vfll Qoutl This result is trivial for example, use the axiom 
O v j? but we need a proof which expresses the reasoning above. This is because the reasoning above gives 
(loosely) “if q out is low on a certain interval, then it is low on another (slightly later) interval . Then, 
ultimately. q ouf is low permanently. 

We call that result latch_step. Here is the proof of the abstract result using the abstract connectives, 
following the proof in [4. §3. equations (2) to (5)]. 

Assume 

ffp ' 2 lljlglill . (O v i?) 

O 2 Ov dl & in D Ovdl Qout [) 

0 3 d1 ,s »nD A dl flout D dfloutD Ov(d>.4 ^ dl^oufD) (0 v f) 

dfloutl) * dl flout 1) OvdflwD (o v F) 

Cvdl Qout [) 

This tree proves dlfloutD OvdIfloutDi an< l dl <?ou/ D “ * Ov (11 flout D follows trivially 

As in the “Tiny” example, this proof can be translated to a proof of the concrete goal p € dlfloutl) □ 
Oy dlfloutD for some appropriate p. which is calculated in doing the Isabelle proof. 

The file Memory2.ML gives a proof which precisely mimics the abstract, proof above, using the correspond- 
ing rules shown in Tables 1 and 2. 

A rule is now needed to incorporate the repeated use of latch.step (which incorporates steps (b) to (d) 
in the proof outline above). The inductive property of a set is defined in [4] thus: 

Ind P ee a- G P □ (P □ Oy/ 7 ) □ O v F ( ! ) 

(where x is a specific value, given in [4]). and it is proved that Ind d^D l |ol, l s f° r a,1 >' P - Ir s<H ' ms 
to describe the proof of this result as an abstract proof where the implementation calculates the constraint 
automatically. The proof seems tailored towards the desired constraint much more than in the “Tiny 
example, or in the proof of latch_step. Proofs of this result are given in Induction. ML. Later, m §2.6. we 
describe a different way of using latch.step to prove the required result, first focussing only on the proof 
at the abstract level. 

We can now use the induction rule d^D -* (d^D Ovd^D) -» Ovd^D in the following proof. 
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0\ Opt 

(jr»iD (HflmwP dr/„D ^ ( latch-step ) 

(Pfl»«* D (jlfluufP Ovdl</r>!0 I) 

OvdV/o.oD 


( induction rule) 


Again, wo convert this proof using Tables 1 and 2, and the constraint is calculated for us; see Memory2 . ML. 


2.6 Alternative Approach 


In part of the proof described above, we considered an abstract proof and performed the corresponding 
concrete proof in Isabelle, letting Isabelle generate the relevant constraint. However the proof of the induction 
rule did not follow this pattern; rather, the proof seemed to be targeted at the desired constraint . We t ried 
to improve this by proving forwards from the rule latch_step. 

Firstly, two intervals which overlap can be combined to form a single interval. We can express this as 
x € dF’D => y € d^D => S C dPD where S = 0 if x and y do not overlap, and 5 = {.r U y) if they do. The 
abstract version of the rule, called During.overlap*, is flPD -> (|P[) -> OyflPp. 

The result latch.step expresses that from an interval in dl<w[) we derive a set of intervals in (jl< 7 „„,|). 
Of this set of intervals, those that overlap the initial interval can be joined with it. giving a set of intervals 
which are at least, as long as the initial interval. 

Here is the abstract version of this. Note that the assumption appears twice, which reflects the fact that 
the initial interval is used twice, once to generate a set of intervals, and once to join with each of them. The 
result obtained, also dl flout P -V dl flout P- is called During_extend. 


Assume 

dl fl««t P 

dlfl out [) — ► Ovdlw D 


Dur ing.overlap } 


Ovdl^D 


Assume 1 

latch.step 

°vdl flout P (OyE) 


This tree proves dlfloutP =*• OydlflWp, and dl flout P -* Ov(Hg OU fD follows trivially. 

At this point, we realized that we want our subset S of fllwD to be closed under “shrinking from the 
right’ ; that is, if (a. b) G S and 1/ < b then (a, b f ) G 5. It is obvious that if («, b) G (\P\) and b f < b then (a, b f ) G 
(jP|), that is, if (a, b) G (\P\)>. then {(a,//) \ b' < b} G Ovd-P(). so this gives the result During_shrink_right. 
which is. abstractly, Qf’D — > OyflPD. Lsing (O v C) we combine During_shrink_right and During_extend 
to give During_extend_all. 

By During_extend_all we have (a, b) G dl(/oufD ^ S C dlqwD where S contains intervals which extend 
(a, b) to the right. We want, to repeat this ad infinitum , forever accumulating larger intervals in S. To do this 
we used Isabelle’s inductive definition facility, as follows. The code shown defines rep h x as the smallest set 
satisfying rules repll and repI2, and it is easily proved, as rep_fp. that rep G (P □ O V P) □ (P □ OyP). 

consts rep :: "(’a => ’a set) => (>a => ’a set)" 
inductive "rep h x" 
intrs 

repll "x : rep h x" 

repI2 M [l 2 : h y ; y : rep h x |] ==> z : rep h x M 


Finally, we combine rep.fp with During_extend_all to get latch_abs_rep. Note that, as abstract 
results, latch.step. During_extend, During_extend_all and latch_abs_rep are all the same, ie flltfoutD 
OvdlwD- However they have different (and successively more complex) constraints. 

Having obtained this result using (we thought) the correct logic, we then set out to check that the 
constraint obtained was equivalent to the one found previously - in fact it turned out that latch_abs_rep 
was a stronger result (had a weaker constraint) than the earlier one. 
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2.7 Comment on Proof Style 

The fil(' Memory . ML gives proofs of the “latdi_atep” and the final result. The proofs of corresponding results in 
Memory2 . ML and Memory3 . ML are very much shorter. While the results proved in Memory2 . ML and Memory3.ML 
contain somewhat different constraints from those proved in Memory. ML. it is not unduly difficult to show 
the equivalence between them (see §3). 

In fact we can attribute our success in streamlining the proofs to the concept, outlined in [4, p. 4j, where 
the authors say 

Our contribution. Our approach involves maintaining a close connection between abstraction (the de- 
ductive dimension) and constraints (the algorithmic dimension). Tin* algorithmic aspect corresponds 
to the calculation of constraints. . . . 

In the proofs in Memory2.ML and Memory3.ML. we have first performed a proof by looking only at the abstract 
parts of the terms. In fact we did this bv working out the corresponding proof in Lax Logic as shown m the 
proof trees above, and then translated this using Tables 1 and 2. While we were concentrating solely on the 
abstract “side” of the formulae (on the right-hand sides of the ‘6’ in the rules in the second column of the 
tables). Isabelle was constructing (or calculating) the constraints on the left-hand sides of the '€ . 

As can be seen in Memory2.ML and Memory3.ML, this made for quite short proofs. Only then did we turn 
to the constraints, proving that t hey were equivalent to the desired constraints (that is, the constraints found 
in the results in Memory. ML). This whole process made for shorter proofs than those found in Memory. ML. 


2.8 Different proofs 

It was observed earlier that the latch.step result could be proved (abstractly) simply by applying O v-R- 
This would give, however, a different concrete result (i.e, with different timing constraint term), which would 
not have been what we wanted. For another example, the important result rep_fp corresponds to the trivial 
abstract result ( P -> O V P) -» {P -* OyP), but the trivial proof would give a different concrete result. 
This illustrates that taking an automated proof of an abstract result and then converting it to a proof of 
the concrete result will often not give the desired constraint. Likewise, we have noted that several distinct 
concrete results, with different proofs, correspond to the same abstract result as does latch.step. It is 
necessary to take into account not only whether the abstract result is provable but how it may be proven. 
In this sense our abstract rules are intended to be used more like tactics than theorems. 


2.9 The “Factorial” example 

In [7], Mendler gives some practical examples. We consider his “Factorial example, where he defines an 
implementation of the factorial in terms of implementations of an “increment” function and of multiplication, 
both of which can handle integers only up to a certain size. 

In this example, the factorial function is implemented using the usual recursive definition, but using 
functions i (for incrementing) and m (for multiplication), which implement, the mathematical successor and 

multiplication functions subject to constraints. c 

The results are in the file Factorial .ML, with definitions in the file Factorial . thy. The functions 

Mendler used are as follows: 

fact, Sue and * are the true factorial, successor and multiplication functions, 

i and m are implementations of the successor (or increment) and multiplication functions, which are 
correct up to constraints 

ent is an implementation of the successor function— in effect, ent n = i n 1 

cnt_0 "ent i m 0 = Sue 0" 

cnt_Suc "ent i m (Sue n) = i (ent i m n)" 

fac is an implementation of the factorial function, using ent 

fac_0 "fac i m 0 = 1" 

f ac_Suc "fac i m (Sue n) = m (ent i m n) (fac i m n)" 
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Note that cnt and fac art 1 defined in terms of i and m, which is a detail necessary in the source 1 code 
but omitted from the Figures 4-7 and 4-8 in [7]. We also note that this implementation assumes that a given 
argument can he correc tly identified as being equal to Sue n there is no constraint for the accuracy of this 
step. 

Figure 4-7 in [7] gives an inductive proof that the function cnt implements the successor function, based 
on a premise that i also implements the successor function. We followed this proof, generally substituting 
rules on the right-hand sides of Tables 1 and 2 for those on the left-hand sides. As the proof in Figure 4-7 is 
by induction on the natural numbers, we show nat .induct, the concrete equivalent of the induction axiom. 

P 0 Vn.P n -> PjSuc n) a E P 0 / G | | n.P n -> P(Suc n) 

Vn.P n nature a f E f~| 11 *P 71 

where nat.rec is defined by 

nat_rec f g 0 = f 

nat_rec f g (Sue n) = g n (nat_rec f g n) 

Recall that previously, where the abstract expression was a boolean condition, the constraint, was that the 
condition would hold only at certain times. Therefore the concrete quantity corresponding to the abstract 
condition was the set of times at which the condition would hold. 

Here the constraints art 1 themselves simply boolean conditions. To use the same concrete rules as previ- 
ously, we 1 use a function / of type bool -> unit set , where /{true) - {()} and /{false) - {}. (unit is the type 
with just one value. ‘()\ and so unit set has two values, {()} and {}). 

We first proved a goal of the form 

/ E r| rc(OvM?’ n — Sue n))) 

?<7 E P| ?i(Ov(r(c/i£ i m n = Sue n ) ) ) 

where ?g denotes a variable which would (usually) become instantiated during the course of the proof. 
Observe that ' } .g could always be instantiated by the function g ti - {}, but the proof process gives us the 
“largest” possible g (in terms of /). That is, assuming f n is {()} whenever i n = Sue n holds, then / n is 
{()} whenever it follows (according to the proof in Figure 4-7)) that ent i m n = Sue n. The Isabelle proof 
instantiates g to naLrec\()}{Xnx. \J((\y.f(Suc n)Yx)) This gave the result deriv2. 

From here we look at the proof in Figure 4-8 of [7], and attempt to prove a goal of the 1 form 

/ E PI n.(Oy(/(i n ~ Sue n))) g E f] n \ n 2 .(O v(/(m ti i lb* — n i * ;?•>))) 

?// E P] ri(0\/(i(fac i m n — fact n))) 

The proof in Figure 4-8 is not quite complete for our purpose, as it shows only a proof of the premises of 
the main inductive step. But using Figure 4-8 of [7] plus that inductive step we obtain the result deriv4 in 
Factorial .ML. 

We then applied these 1 results, choosing, as constraints for the functions i and m, the conditions that the 
result fits into a word length of w bits. So our constraint for i n = Sue n is Sue n < 2 W \ and our constraint 
for m m ri 2 - n\ * n 2 is n x * n 2 < 2 W . (These constraints are expressed in the functions I and M, defined by 
I_def and M_def ). 

We then simplified the constraint of deriv4. This involved a few theorems which may be generally useful 
in dealing with the unit set type, and some theorems specific to the constraint being simplified. Finally we 
obtained the theorem deriv4 J 1, which gives the constraint (n = 0 | fact n < 2 U ). Expanding the definitions 
of the connectives Ov* n. i and the definitions of I and M, and applying a little automatic simplification, we 
obtain a correctness theorem of the form 

Vn. Sue n < 2 W -fr i. n = Sue n Vni , n 2 . rq * n- 2 < 2 W — > m n 2 = n\ * n 2 
V ii. (u — 0 — ► fac i rn 0 = fact 0) A (fact n < 2"' — » fac i m n = fact n) 

In fact we weren’t expecting the disjunct n - 0 in the constraint of deriv4 , l, but it is clear that it 
should be there. The reason is that fac i m 0 can be evaluated without using the implementation of / or 
777 -it is defined as 1. (An alternative definition of fac might have been fac i rn 0 = i 0). We mention this 
only because it is reassuring to get an unexpected result which, on reflection, proves correct! 
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3 Dealing with the resulting constraints 

As mentioned, this approac h lias the significant advantage that constraints can be calculated automatically. 
Typically, at each step of the proof, the constraint attached to the current proof becomes larger and larger. 
It may therefore require' significant effort to sirnplfy the constraint to a point where it is useful. For example 
the constraint appearing in deriv4 (before substituting the actual constraints on i and m (increment an 
multiplication) for / and (]) is 

nat-re<:{ ( ) } ( \nx.nuLrcc{ ( ) } (Mix . \J((\y.f(Suc n))'x))n n g(Suc n)(fact n) D x) 

In the ease of the “Latch’’ example, part of the constraint was the expression 


(Vf| + D[ < 1 1 -4 (3.S 2 .S + (i\ < S'2 A S'2 <t i A 
(3f-j.fi < U A (3«..s> = max a (s + d \ ) + d> + d i A 
(3b.t> — min b 1 1 + D> + D\ A .s < a A a < b))))) 


which can be simplified to 


2 * di + (.s + d 2 ) < t + D x A (0 < D-i | 0 < D { ) 

We felt, that the form of the constraint produced would be likely to recur in other cases in connection 
with timing constraints for hardware, and so we developed some conversions to assist the simplification 

This simplification requires removing all five of the quantifiers. We produced four conversions which 
in various ways remove quantifiers automatically. All five quantifiers in this example were removed by the 
conversions we produced, which suggests that they may he of some general use. 

The actual simplification, with and without use of the conversions, is in the file Memory2.ML. 


3.1 Conversions 

The concept of a “conversion” is found in the HOL theorem prover, see [5, Chapter 13]. where a conversion 
is a function of type term -> thm. which takes a term f to a theorem t = t' (which can be used to rewrite f 
to t') \ conventional is a function which acts on or modifies conversions. For example, if coni; t is f - f (to 
rewrite f to f'), and com / f is t' = t" (to rewrite f to t") then (com, THENC com/) t is t = t" (to rewrite t to 
t n ). The conversional SUB_C0NV applies a conversion to the immediate subterms of a term. These eonversionals 
may be used to program various more complex strategies for rewriting (where possible) subterms of a term, 

as described in [5, §13.2]. , , 

In HOL, a conversion com , that “fails” , in the sense that com, t finds no f such that f - t , can be 
programmed either to return t = t or to raise an exception (and there are functions to change one sort of 
conversion to the other). We implemented this concept slightly differently. Our conversion has type cterm 
-> thm option (a cterm is a term “certified” to be type-correct). Given f. if an equivalent but different 
expression f' is not found, then (normally) NONE is returned (we say the conversion “fails”) though some 

conversions will return t — t (we say they “succeed trivially ) 

The structure Conv (file conv.ML) contains many functions relating to conversions. (All have close coun- 
terparts in HOL [5. Chapter 13]). For example, the following three functions apply cj and/or c 2 . but with 
different results depending on their success or failure. 

Cl THENC C 2 applies rq and then c 2 , failing if either <q or c 2 fails, 

c , BOTHC c -2 behaves just as c 2 if o t fails, but if ci succeeds it tries c 2 on the result of n; it fails only it 
both c\ and t* 2 fail, 

cj ORELSEC cy tries n, and tries c 2 if c\ fails. 

For a single conversion <\ 

TRY.CONV c t tries r t, succeeding with / = t (succeeding trivially) if e t fails 
REPEAT 1C c repeats c until it fails, succeeding only if c succeeds at least once 
REPEATC c tries c repeatedly until it fails, but always itself succeeds 

Clearly a conversion which can succeed trivially should not be REPEATC-ed, or an infinite loop may result. 
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For a conversion e, where t is t \ t>, C0MB_C0NV c t applies c to ^ and to U\ where t is A x.t! , ABS_C0NV 
c t applies r to f'. 

With these building blocks, we can define TOPDN.CONV and B0TUP_C0NV; T0PDN_C0NV c t applies r to all 
subterms of A without repetition, in top-down order, and likewise BOTUP.CONV r A in bottom-up order. 

Depending on r, either TOPDN.CQNV (REPEAT 1C r) or REPEAT1C (TOPDNXONV (REPEAT1C r)) may be 
conversions which achieve more (but are slower) than T0PDN_C0NV c. 

The functions C0NV_G0AL_TAC : conv -> int -> tactic and C0NV_G0ALS_TAC : conv -> tactic 
turn a conversion into tactics which will alter a given subgoal, or all subgoals respectively. The function 
C0NV_RULE : conv -> thm -> thm option uses a conversion to turn a theorem into a new one. 

More such functions and conversionals an' available in the file conv. ML. 

3.2 Ex_eq_conv 

Given a term of the form 3x y z. P x y z A y = / x z A Q x y z clearly the only possible solution for y is 
U = f x z. Therefore the term is equivalent to 3x z. P x (/ x z) z A Q x (/ x z) z. 

The conversion ex_eq_conv' actually ccmverts the original term to 3x y z. P x (f x z) z A / x z = 
f x z A Q X (/ x z) z (i.e. converting y in the body of the original to / x z)\ Simp^tac will simplify this to 
3.r z. P X (/ x z) z A Q x (/ x z) z. 

Given a term such as 3x. P x A (3t/. x = a + y) A Q x we can rewrite it to move existential quantifiers 
outwards, to make ex_eq - conv > applicable. (Note that default simplification will do the opposite', i.e. move 
quantifiers inwards where possible). 

3.3 Ex_mono-conv 

Given a term of the form P x x, where the notation P x x implies that x appears in P in two (or more) 
places, and where P is monotonic in both (or all) of those arguments, then the term 3x } .r 2 . P x } x 2 is 
equivalent. This is because, given any solution x ] ,x 2 for the latter, x = max(xi,x 2 ) will suffice as a solution 
for the former. 

The conversion ex_mono_conv » performs this conversion. The resulting term may well not seem “simpler’ 
than the original, but it can allow further simplification. For example, 3x. a < x*bAc < x can be converted to 
3xi x 2 . a < x\ * b Ac < x 2 , and thence (by default Isabelle simplification) to (3x \ . a < x\ * b) A (3x 2 . c < x 2 ): 
then the second conjunct can be simplified away. 

3.4 Exjrel-conv 

The conversion ex^rel.conv' converts a. term such as 3x y. P y A b < x - y to 3x y. P y A True. It depends 
on establishing that the conjunct b < x - y can be solved for x. 

The result in the example can be simplified to 3 y. P y. It works where there are several existential 
quantifiers together (as the example given above*) and multiple conjuncts. As in the case of ex_eq_conv’, 
it may also be useful to first rewrite so as to gather the existential quantifiers together outside a set of 
conjuncts. 

3.5 Exjrm.conv 

The conversion ex_rm_conv is used to convert a term such as 3y. x < y A P y. where P is antitonic in y , to 
P x. The reasoning behind this is that y — x is the unique minimum possible solution to the first conjunct 
for y 1 and since P is antitonic in P x holds if and only if P y holds for some y such that x < y. 

4 Conclusion 

W e have shown how the use of Lax Logic to handle constraints and of the Isabelle theorem prover to perform 
proofs can achieve the “clean yet sound separation" ([4, §4]) of reasoning logically about the properties 
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which “ought'' to hold and calculating (in the theorem proven) the constraints under which those properties 

actually do hold. . x . „ 

We have shown also described a number of conversions suitable for simplifying these automatically gen- 
erated constraints in the case of the timing constraints for hardware. Although the automatically generated 
constraints can be complex, the conversions we have described are powerful tools for simplifying them, and 
we suggest that they would be- generally useful for constraints calculated using our method. 

Our approach is motivated bv practical considerations and does not aim for complete generality. An 
alternative and more general approach would be to apply Norrish's work on implementing Cooper s algorithm 
in HOL [10]. This algorithm is a decision procedure* for Presburger Arithmetic and relies on a method of 
transforming a formula into a quantifier-free normal form: since our focus in constraint analysis is not merely 
on proving constraints (that is, on showing they are redundant) but more* generally in simplifying them it 
is the* construction of normal forms that interests us. In the above example of the latch, the final form of the 
constraint is indeed quantifier-free, and considerably shorter than the constraint initially generated. However, 
there* arc* instances where quantifier elimination would greatly increase the size of a constraint , and ill those 
cases a more* compact formulation involving quantifiers might be* more intelligible and therefore preferable. 

Our constraint-based approac h to machine-assisted reasoning would provide a wealth of examples that 
could be used to compare these two approaches. 
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Abstract. Work with Pitts and others has led to FM (Fraenkel-Mostowski) theory, a fresh under- 
standing of modelling syntax in the presence of variable binding. We discuss the design and other 
issues encountered implementing these techniques in the mechanised theorem- prover Isabelle. 


1 Introduction 

It is easy to declare a naive datatype of terms of some language, for example the untyped A-ealeulus, 

.1 — fiX A ar of Nat + App of A' x A" -f Lam of Nat x A" (1) 

where Nat is the natural numbers. Problems famously arise defining program transformations in the presence 
of variable binding. For example a substitution function [t/a]s on A above should avoid “accidental variable 
capture 1 in [Var(l)/Yar(0)].s for .s = Lam(l, Var(O)). Thus we rename 1 in s to some i / 0, 1, but then Var(i) 
is no longer syntactically a subterm of ,s and we have made an arbitrary choice about the value of i. The 
former point causes difficulty with structural induction, the latter because we may have to formally prove 
irrelevance of the choice made. 1 

All this we could do without., especially in the unforgiving structure of a computer proof assistant such 
as Isabelle, HOL98, or COQ, or even programming in some language with datatypes. There is much research 
in this area, for example explicit substitutions ([2]), de Bruijn indices ([3]). and HOAS ([11], [4], [9]). 

FM theories are another approach with a pleasingly elementary mathematical foundation. See [7] (my 
thesis), [5] and [6] (set theory), [8] (higher-order logic), [13] (programming languages), [12] (first-order logic). 
The label “Fraenkel-Mostowski” honours the creators of set theories designed to prove the independence of 
the axiom of choice, see [15]: a very special Fraenkel-Mostowski set theory was the first FM theory in the 
sense of this paper to be created. 

In this paper we discuss principles of formally implementing a theory of FM syntax, based on experience 
doing so in Isabelle [14]. 

The first, design decision of the implementation is the choice of system, Isabelle. We chose Isabelle 
for its paradigm of constructing arbitrary useable theories (Isabelle/Pure/FOL, Isabeile/Pure/HOL, Is- 
abelle/Pure/CCL, .... see [14]) in a fixed weak meta-language Isabelle/Pure. This meta-language is a very 
weak higher-order logic (HOL) containing little more than modus ponens, but to which we may add new 
types, constants of those types, and axioms on those constants. Thus we may axiomatise a theory in Is- 
abelle/Pure and then work inside that theory. This is good for prototvping a new foundational system such 
as FM. 

2 FM 

'FM 1 may differ depending on whether we do computation or logic. For example compare the typed A-calculus 
(a theory of computable functions) to higher-order logic (a theory of all functions). This paper is about logic, 
FM in computation (programming languages, unification) is under development, see [13,1]. 

* The author gratefully acknowledges the funding of UK EPSRC grant GR/R07615 and thanks Andrew Pitts for 
his suggestions for improvements. 

Cf. the work of McKinna and Pollack in the LEGO system, e.g. [10]. FM is quite different, but sometimes echoes 
this work. 
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-FM’ is a set of techniques for o-equivalenee with inductive definitions and not a particular tliwry. We 
shall now present FM in the style of a higher-order logic. This is not an axiomatic presentation (see 18]) hut 
a 'sketch of salient features, in the style of higher-order logic’. First, three preliminary remarks: 

1 (Types). We shall write type annotations in two styles: x : a and x" both mean "x of type a . 

2 (HOL sets). Higher-order logic has a notion of set, when' ‘n-sets' is predicates o y Bool also written 
V(n). We borrow set notation, for example writing x 6 A" for '(X x) , A C 5 for ‘Vx. (A x) -> (1 x) , ati^ 
0 for Xx.± and a for Ax^.T . 

3 (Meaning of infinite). In FM theories not all types can be well-ordered (Injected with an ordinal see 
[8, Lemma 4.10(5)]). Therefore, a reading of A is infinite’ as A = N is suspect . In FM we use A 0 

where Vf,„(X) is the inductively defined type of finite subsets of A . 

An FM theory has: 

4 (Atoms). An infinite type of atoms a. b. c : A to model variable names. For example in an inductively 

defined type of expressions for types, 

w TypeVar of A + Product of A x A + DisjSum of A x A, (2) 


type variables are represented as TypeVar(a) for a : A. 

5 (Transposition). There is a (polymorphically indexed class of) constant (s) 

Tran : A — > A — » o — > <7, 


read “ transposition ’. Write (Tranabx") as (a b).x. The intuitive meaning of (« b) x is as transposing « 
and b in x. For example if x = <a. b> then (a b).x should equal <b.a>. This is made formal by the following 
equational axioms which Tran must satisfy, and equivariance below . 

(a a).x = x 

(a b).(a b).x = x ^ 

{a b).(c d).x = (r d). ((c d).n (c d).b) .x ( c ) 

(a b).n A = if {n = a, b. if(n - b.a . n)) ( • ) 

where if (test, t x , t 2 ) is Isabelle-like notation meaning “if test then f i else t- 2 . 

6 (Equivariance). For a term / with free variables xi,...,x„, 

(a b).f( i,,....:r„) = f((a b).Xi,...,(a b).x„). (8) 

In the case that / has no free variables we have the special case that (a b).f /- 

We say the language is equivariant. An equivariant element x is one such that for all a, b. (a b).x = x. 
From (8) for n = 0 it. follows that closed terms denote equivariant elements. ° 

Definition 7 (Smallness, 1/1). Write V fin ( A) for the HOL set of finite subsets of A. Say a set X Q A is 
co finite when its complement A \ A is finite. Write P ro/ill ( A) for the HOL set of cofimte subsets of A. For 
p ; A -t Bool write ‘1/1 P' or ‘Mr/. P(a) ’ for P € V co fn i(A). 

A is infinite from remark 4 so we can read Via. P(a) as “for all but finitely many a : A. P(a)” , or more 
loosely as “for most a : A. P(«)”. We may call finite P : A -» Bool small and their complements, cofimte 
sets, large. Thus P is large precisely when 1/1 a. P(a), and small precisely when V\ a. —>P (a). 

Definition 8. Define «#x '= (Vlb. (b «).* = *) and read this as “a is not ‘in' x” or “a is apart from x". 
The intuition is that, since transposition transposes b for a in x and since b is fresh, if (b a)..r - x then 
certainly a is not in x. 
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We have an axiom stating that ‘most’ atoms are not 'in’ x : a: 

H«. <>#■<■■ (Small) 

Expanding definition 8 this becomes Ha. V\b. (a b).x = x. Write 

Supp(z) ‘= f {a : A | 

Then (Small) is equivalent to 

Supp(j-) G Vfin(x) (9) 

and we can also read (Small) as u x has finite support . 

9 (Some observations). k In does not correspond to (HOL-)set membership. For example. 

n £ L = A \ {?/} but n G Supp(L). 

We might think of Supp(x) as an object-level notion of those atoms occurring in some meta-level term which 
x denotes. 

Datatypes of syntax T certainly satisfy (9). Terms t : T arc 1 finite 2 so mention only finitely many atoms, 
and cofinitely many a : A satisfy ajft. O 

10 (H excellent properties). Higher types such as A -4 Bool also satisfy (9). Observe that (using some 
sets notation) 

P : A — » Bool = {x | P(x)} . 

It follows from (8) that 

(a b).P = {(a b).x | P(x)} . 

We can verify by calculation that (a b).P = P if and only if a. b G P or a, b $ P. When we combine this with 
(9) it follows that either ‘most’ atoms are in P or most are not in P: 

P(A) — P/m (A) H- V co fj n (A). (10) 

We can rewrite this as -»l/la. P(a) & l/la. -P(«). Now the full set Ax.T = A C A is clearly cofin ite 
so 1/1 a. T — T. Combining this with other properties of cofinite and finite sets we obtain the algebraic 
con i mut at i v i tv properties : 


Mo. P{a) A Ha. Q(a) 

<=> l/la. P(a) A Q(a) 

(ii) 

l/la. P(a ) V l/1a. Q(a) 

<=* 1 /la. P(a) V Q(a) 

(12) 

Ha. ->P(a) 

<=> -Ha. P(a) 

(13) 


l/la. T 

(14) 


-l/la. ± 

(15) 

(Ha. P(a)) A Q 

<=> l/la. (P(a) A Q ), 

(16) 


that is, 1/1 distributes over A, V, — T and _L. These strong properties make l/l convenient to work with 
in a mechanised context. They also place \A in an interestingly 4n between’ V and 3, the equations being 
informally: 

— V— = 3 — >1/1— » = 1/1 -f3-i = V. 


O 


2 Extending FM to infinitary syntax is possible and interesting. 
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3 a-equivalence on a simple datatype 

11 Tran is how an FM theorv renames object-level variables. It interacts with object-level syntax better 
tlian atom-substitution [b/a]. For example [b/a] applied to / = Lam(«).Lam(ft).n(ft) raises all the usual 
problems with capture' avoidance, whereas (b <i).t = Lam(«).Lam(ft).ft(«) is n-equivalent to 1 itself. Siinil.nl>. 
(b a). (A \ {«}) = A \ {ft} wheras [b/a]( A \ {«}) = A \ {a}. 

We can define an a-equivalence relation = a by cases on inductive types. Foi example. 

Definition 12. 

L ‘= Ty Var of A + TyProd of L x L + TyAbs of A x L 

= n ‘= f TyVar(n) = a TyVar(h) <- a = b 

TyProd(t] , t->) =„ TyProd(t\,t' 2 ) «- t\ =« t\ A t 2 =„ t ' 2 
TyAbs{a.t) =„ TyAbs{a'.t') *- V\b. (b a).t = n (b 

Here L is intended to he a type of expressions for types. The definition of L above might be written in more 
familiar style as 

l ::= TyVar(o) | TyProd(/, I) | TyAbs(n. 1) a : A. 
and sugared to (writing a for / a type and a for a : A a type variable) 


(j ::= a hr x (T 


A o. 


a. 


We shall use L, =„. and =„' defined below in (18). as a running object of study in the rest of this paper In 
the rest, of this section and elsewhere the proofs given are semi-formal accounts of the formal proofs as they 

might be conducted in Isabelle. ... 

This machinery allows us to quite easily prove some nice properties for = ft , for example transitivity: 

Lemma 13. is transitive. 

Proof. By induction on syntax using hypothesis 

def 


0(t 1 


(fl =« t> A #2 —n t:i) — > 1 1 — n H- 


The significant, case is of t x = TyAbs(ai , t\ ). So suppose 0{t\), h -a h, and t 2 - a t 3 . Then <2 
TyAbs(a 2 J 2 ) and t 3 = TyAbs (a 3 ,fs)> arid 

(14ft. (ft m).t\ = n (ft rt>)4) A (14ft. (ft a 2 ).t 2 =a (ft 

We now equationallv apply (11) to deduce 

I/I b. ( b a\).t\ = Q (b 0 - 2 ) -to —a {b a :d ^ 3 * 

Now we assumed o(t\). not <p((b a x ).t\). But we can apply equivariance (8) to o(x) to deduce d>(t\ 
0((b a\ )-t\ )■ which allows us to complete the proof. 

We can also define a more traditional n-equivalence 

TyVar(u) ~ a ' TyVar (ft) a = b 

TyProd(ti . t 2 ) = n ' TyProd (t\,t 2 ) <- 1 1 — n ' t\ A t > =„ t-, 

TyAbs(a.f ) =„' TyAbs (o'. t') <- 3ft. [b/a].t =„' [6/a']f'A 

ft 4 n(t) U n(t') U {«.«'} 


□ 


(18) 


in terms of an inductively defined names-of function n(t) 

n(TyVar(a)) = {«} 

7t(TyProd(f i , t 2 )) = n(t x ) Un(t 2 ) 

n.(TyAbs(a, t)) ={a}Un(t) 


( 19 ) 
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and an inductively defined atom-for-atom substitution function 


[6/«]TyVar(a) — TyVar(fi) 

[6/ n]TyVar(n) = TyVar(n) n / a 

[6/«]TyProd(<i . t,) = TyProd([6/«]/ , . [b/n}U) 

[6/a]TyAbs(n, t) = TyAbs([6/a]u, [6/a]/). 


( 20 ) 


n(t) and [b/n]t are simple and make no allowance for free variables or capture-avoidance, but they suffice for 
our needs. 

Suppose we want to prove t { - a t-> O / j =„' /•_,. A pleasing and clean method would be to prove 


V\b. [6/a]/ — (b a).t 

3b. [b/a].t = n ' [ b/<i')t' A b n(t) U n(t') U {«,«'} 

Wk [b/a)t =„' [6/a']/'. 

Proof (of (21)/. We can use structural induction for a fixed with hypothesis <p 

dot 


( 21 ) 

( 22 ) 




1/16. [b/a]t = (b a).t. 


Suppose t = TyProd (/i,/ 2 ). Bv definition from (20), [6/a]TyProd(/! , Z 2 ) = TyProd([6/a]Z, . [6/«]/ 2 ). and 
by equi variance (8), {b a).TyProd(Z, , t, 2 ) = TyProd((6 a).t x , (b By hypothesis we know 

(I Ab. [b/a]h = ( b a).ti) A (I/I b. [b/a]t 2 = (b a).Z 2 ). 

By (11) and applying the equalities under TyProd we obtain the result. 

The cases of TyVar and TyAbs are no different. Each time, equi variance of ( b a) as illustrated in (8) 
allows us to push transposition down through the structure of a term and replicate the inductive behaviour 
of [ b/a ]. This is a general pattern. □ 

Note from this proof how transposition with equivariance has provided a ‘general axiomatic theory of (purely 
inductive) renaming’. 

Proof (of (22)). The proof of (22) is rather more involved. It is best to work from the following lemmas: 


n(t) € P/ IT , (A) 

(23) 

A' € P/i n (A) => (6 $ X o 6# A) 

(24) 

6 £ n(t) <=$■ b#t 

(25) 

b#xAb#f => b#f(x) 

(26) 

& #(/(-*0) A 6#/ A / injective =*> 6#x 

(27) 

hffc c a closed term 

(28) 

6 #pA-> B °°l A m 

(29) 

V\b. P(b) =*• 36. 6#PAP(6) 

(30) 

1/16. P(b) =► V6. 6#P => P(6) 

(31) 

36. 6#x 

(32) 


The proof now proceeds as follows. We must prove 

3b. [b/a]t —a' [6/a']/' A 6 £ n(t) U n(Z') U {a, a'} 


I/IE [b/a]t =„' [6/a']/'. 


tief 

Write P = \a, a* ,t,t* .\b.[bf a]t = a f [b/a f ]t f and use (25) (proved from (23) and (24)) and to rewrite this 

to 


3b. b#t, t\ a , a 1 A P(t , t\ a. a\ b) 


1 Ab. P(t.t f .a.a\b), 
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whore b#x \ . . . denotes the conjunction f\ i />#*,-. 

Left-right implication. We must prove 

3b. b#U\ a,(i A P(t,t'i(i,a\b) ==> W>. P(t, t' . «, &)• 

We eliminate the existential tjuantifier and obtain 

A P(M', a, => Id?;. P(tj\ a. a\ /;). 


We resolve against (29) to obtain 

b#t. t'.a.a' A P(f ,f\ a,a')(b) => b#P(t. t' .a.n') A P(t,t' ,a,a'){b). 

which simplifies to b#t.t'.a,a' ==> h#P{t. t’.a.a'). We repeatedly resolve against (2G) to reduce to b#P, 

and finish this off with (28). 

Right-to-left implication. We must prove 

Mb. P{t.t'.(ua\b) => 3b. b#t, t'.a.a' A ,a,a',b). 

Now here we have a problem. Clearly we would like to eliminate 1/1 using (30) to obtain 

b#P(t.t' .a, a') A P(t.,t',a,a' , b) => 3b. b#t,t' ,a,a' A P(t.,t' ,a.a',b), 

identify the b in the conclusion with the b in the hypotheses, and simplify. But we obtain 

b#P{t.t'.a,a) => b#t,/',«.n'. 

This implication does not follow for general P, nor even for our particular P: if P were injective we c ouid 
apply (27) repeatedly, but it is a predicate mapping into Bool and is not injective. 

However we can use (32) to introduce into the context some b fresh for any x, so instantiate x to the 

3- tuple , 

<n(t) : n{t t ), {a. a }>. 

Now we can apply (27) repeatedly to obtain 

b#t, t'.a. a' A 14b. P(t, t' . a, a, b) => 3b. b#t, t'.a.a A P{t.t' .a. a' ,b). 

(Here there is also a hypothesis b#Ax l ,* 2 ,* 3 .<*„* 2 ,*3> but this gives us no information since we get it 
for free from (28), so we drop it.) This simplifies to 

b#M\«,a'Al4b. P(t,t',a,a',b) => P(t,t',a,a',b). 

But now we have another problem. If we eliminate 14 using (30) wo obtain for a variable symbol b . 

b#t,t',a,a' Ab'#P{tJ.',a,a') A P(t.t' .a.a' ,b') =* P{t,t' .a.a' J>). 

We need a different elimination rule for 14 which does not introduce a new variable into the context , and this 
is provided by (31), with which we can finish off the proof. 


4 Morals from the proofs 

In the previous section we have seen the beginnings of the automated theory of (« b). #, introducing a fresh 
name, and 14. We now bring it out explicitly. 

14 (Theory of transposition). Given a conclusion of the form s = (n b).t , use (8) to simplify the RHS 
by drawing transposition down to the variables on the right hand side. Similarly for other binary predicates 
such as or also #. So for example 

s =z (a b).<x,y> simplifies to .s = <(« b).r.(a b).y>. 

This algorithm can fail, for example on the goal (a b).<x, y> = (a b).<x, y>. Call it push, because it pushes’ 
transposition into the structure of the term on the right of an equality. In an implementation push would 
denote a tactic. We shall continue to give such names to algorithms which would denote tactics. O 
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15 (Theory of #). Given a goal of the form a#t repeatedly apply (2G) and (28) to simplify it to component 
parts. So for example 

a#<x,y> 

reduces to a#.r A a#y A a#\x. y.<x , ;*/>, and then to a#x A a#y. This algorithm can also fail, for example 
in n#7Ti <T. «> we should perform tf- reduct ion first, otherwise we finish up with «#a. which is untrue. Call 
the algorithm split#. <^> 

Inductive proof on inductive types earn with proper handling and properly coordinated automated pro- 
cedures, he made to produce very uniform proof-obligations which are amenable to this kind of treatment, 
with only slightly more sophisticated algorithms. 

16 (Introducing a fresh name). (32) allows us to introduce a new variable b into the context, fresh for 
x for any x: given the proof-state 

V.r i ..... ./*„ . C onds(x \ ..... x „ ) =J> C one! (x \ .... . x n ) 

wo can reduce to 

V./*i ..... x n , b. Conds(x [ , . . . , x n ) A b#t(x j . . . . , x n , b) => Concl(x\ ) 

for any t . 

We can now take t to be the 11 -tuple <Supp(j* 1 ), . . . , Supp(x„)>. Repeated applications of (27) reduce 
b#t to /\jb#Supp(xi). It is a lemma that /;#Supp(u) <^=> b#u, so we obtain 

Vj*j , . . . , x n J). Conds(x ] , . . . , x n ) A b#Xi => Concl(x .\ , . . . , x n ). 

i 

In other words, “we can always invent a fresh 6”. We applied this technique ad-hoc in (34). Call the algorithm 

newname. 

17 (Theory of 1/1). The treatment of \A is more complex. There are two broad styles of reasoning on l/l , 
equational reasoning using for example properties such as (11) and (16). and directed reasoning using intro- 
and eliin- rules such as (29), (30), and (31). Both are useful. For example 1 equations in (17), and intro- and 
elirn- rules in the proof of (22). 

A further complication of the treatment of intro- and eliin- rules is that 1/1 seems to have* two pairs of 
them. In full, they are 

3b. (b#r A ^*° 01 a p(b)) => m. p(b) (35) 

V\b. P(b) =S> (36. b#PAP(b)) (36) 

V6. (&#P A - B ° o1 -> P(b)) =#. 1/16. P(l>) (37) 

m. P(b) =► (V6. 6#P =>. P(6)). (38) 

For practical purposes these pair off naturally as (35) with (38) and (37) with (36). The first pair requires 
we find in the context a fresh 6. The second pair introduces that fresh 6, but only fresh for P. Wo can do 
better than this using (32) as in remark 16, so this latter pair seems less useful. 

The complete algorithm is therefore: simplify using (11) to collect all I/I quantifiers in the hypotheses into 
one single quantifier. Also use (13) to draw negations under the 1/1 quantifier. Finally, apply the intro- and 
olirn- rules (35) with (38). possibly augmented with remark 16 to generate a fresh name where necessary. 
Thus for example 

Vpar arris. \Aa. P(a) A — « l/| r/ . Q(a) =£► -'Via. R(a) 

simplifies to 

Mparams. Via . P(a) A iQ(a) => l/l a. -»/?(a), 

a fresh b is introduced 

Vparams, b. b#params A l/l a. P(a) A ->Q(a) => l/l a. -• 72(a), 
the intro- and elim- rules reduce this to 

Vparams, b. P(b) A ->Q(6) ==>• -./?(&), 

and proof-search proceeds as normal. In the case that the fresh b is already in the context, as happened in 
(33), we use that supplied b instead. Call this algorithm news imp. O 
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5 Difficulties implementing the algorithms 


There are many technical difficulties putting the ideas of section 4 into practice. 
18 (split#), split# is described in remark 15. The steps of the algorithm are: 

1 repeated resolution with (2G) followed by, when this fails. 

2. resolution with (28). 


There are difficulties with both steps. 

1. Isabelle resolution with Isabelle unification is higher-order. o#/(x) unifies with a goal a#t for x matches 
t and / matches Ax.x the identity, and we have a non-terminating loop. The solution is to write ML code 
to only allow this step when 1 is syntactically an application term tl $ t2, and package this up as an 
Isabelle wrapper. An Isabelle wrapper, simplistically put. is an Isabelle theorem ‘wrapped’ in ML code 
which provides some intelligent control oil how it may be applied, see remark 20. 

2. It is impossible at object level to decide whether a term of the meta-level is closed or not. Again, we 

need an ML wrapper. 

The algorithm push described in remark 14 is similar and also requires wrappers. ° 

19 (newname). To introduce a fresh b fresh for all variables *„ in the context, as we saw in remark 10 

we must examine those names. This is. as in the previous remark, an operation on the meta-level syntax and 
must be implemented by an ML wrapper which examines that syntax. 

20 (Isabelle wrappers). We observed in remarks 19 and 18 that three significant F\I features require 
ML wrappers in implementation (split#, push, and newname ). 

Isabelle proof proceeds imperatively by applying tactics to a proof-state. Simple tactics may apply a 
particular transformation to the state. More complex tactics will carry out some kind of proof-search. These 
automated tactics (written in ML) give Isabelle proving much of its power. They are all essentially tree-search 
algorithms of various kinds based on a library of Isabelle theorems which may be equalities, intro-rules, elini- 
rules, as the case may be. In inductive reasoning we use this automation to automatically handle the dozens 
if not hundreds and thousands of separate cases which a proof may entail. Wrappers are applied m between 
proof-steps and perform well as intelligent agents which may examine the way the proof-state is developing 
and perform for example some kind of garbage-collection. 

But. consider the example of split#. This is implemented as a wrapper as discussed above in remark 18 

but morally it is clearly a pair of intro-resolution rules: 


a# / A a#x 


a #/x and «#c if c closed. 


In proof-search however split# will only be applied if none of the standard Isabelle theorems is applicable. 
We cannot, using wrappers, interleave it ‘horizontally’ with the standard Isabelle theorems, only ‘vertically 
with lower precedence, and in consequence proof-search is inefficient. Unfortunately there swims no cure 
other than dedicated FM proof-search ML code, or to hack existing code to hardwire algorithms such as 
split#, push, and nevsimp. 

Now consider our treatment of the logic of I/I. This consists of equational theory such as (11) and (16), 
of intro- and elirn- rules 


a#P, P(a) => V\a. P(a ) and (1/la. P(«)). a#P => P(a), 


and of newname discussed in remark 1 1 . . 

I„ this and in the equations immediately following we introduce two items of notation. A h( ‘ re IS not 
a conjunction (as previously used written A, prop,) but a meta-level Isabelle/Pure universal quantification 
(Ax. prop(x)). Also, a comma , denotes meta-level conjunction. I shall not be completely strict about 
distinguishing meta-level Pure from object-level HOL, but A ail(1 • where used will definitely denote the 
former. 

As a simple example of a proof involving 1/1 consider a proof of 


f\P.Q. Ha. P(a), Ha. Q(a) => Ha. P{a)AQ(a). 


(39) 
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Inductive reasoning tends to be resolution-based, so we prefer an algorithm in that style. Accordingly we 
apply the intro- and elim- rule's above, along with the conjunction intro-rule A, 13 => A A B, to obtain 

f\P.Q. PC'a(P-Q));QCMP-Q)) => MP-QWP 
/\PQ.P(MP,Q)),QmPQ)) => MPQ)#Q 
[\P,Q. PC!a(P,Q)),QmPQ)) ==> P(MPQ)) 

/\P,Q- PC!<i(P.Q)).QC>b(P.Q)) => QC>b(PQ)). 

Here ?«(P, (/) and ?6(P, Q) are unknowns which may be instantiated to any expression with free variables at 
most P.Q . The two freshness subgoals cannot, be proved. We can use' newname to introduce a fresh parameter 
into the context., but that only gives us 

f\P.Clb. P(?a(P,Q)).QC!b(PQ)).b#P,b#Q => ?a(P.Q)#P 

and 7a (P.Q) cannot be instantiated to b because b is a new free 1 variable not amongst P.Q . Thus we need 
to apply newname before the resolution steps and then the proof succeeds. 

In another situation such as proving (31) the fresh name may be provided by the previous proof-context, 
and we certainly do not want to apply newname: it will cause unknowns to be instantiated to an irrelevant 
fresh parameter. It seems difficult to express a sensible and efficient compromise algorithm for this kind of 
proof-search . 

In the rest of this section we step back and take a high-level view of these problems. In Isabelle and other 
theorem p rovers there are actually two kinds of variables. Free variables «, b, ;r, y and unknowns la, lb, lx, ?//. 
Free variables are ‘universal’: they have an arbitrary value which ranges over all possible values. Unknowns are 
‘existential’: they should, by the end of the proof-search, he instantiated to some specific term t . With these 
built into the meta-level of Isabelle/Pure the intro- and elim- rules for universal and existential quantification 
are easy to write. This need not be the case. For example in second-order A-calculus existential quantification 
can be expressed using universal quantification. Theorem provers do not use this because' it is nasty to work 
with in implementation. 

It seems that the underlying problem may be that we are trying to encode using both a and la a kind 
of ‘freshness’ variable corresponding to the ‘new’ quantifier 1/1. The fact that we need both reflects the V/3 
duality of 1/1 mentioned in remark 10. Like unknowns, la a freshness variable depends on a context, for 
which it is fresh, and two sufficiently fresh freshness variables may be assumed equal, ‘instantiated to each 
other’, where convenient (think for instance of proving (11) or (12)). Like universals, freshness variable's when 
introduced extend the context, and other terms and variables may depend on them if they are introduced 
later (e.g. other freshness variables). Trying to usefully express this in a dedicated logic belongs to future 
work. 

6 The technical lemmas 

This section can be skipped. For the interested reader we show a simple algorithm in action, constructed 
using the tactics developed in section 4. The point is that it neatly settles most of (23) to (32), which means 
we have a decent algorithm. We skip to the fourth one (26) b#x A /;#/ => b#f(x). 

Unfold definition 8 and apply newname. We obtain 

AM,/. I Ac. ( cb).x,\Ar . {c b).f => I/If. (cb).f(x). 

Apply newname 

f\b,x,f,c. c#b,x, fV\c. {c b).3 r, l/lr. (c b).f => I/If. (r b).f(x) 

then news imp to obtain 

A b.x.f.c. c#b, x. f {‘!cl(b, x, f, c) b).x = x, (?f 1(6, x,f.c) b).f = f 


(?c2 (b.x.f : c) b).f(x) = fix). 
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It is now simple to instantiate ?el (b. x. f, r) and ?r:2 (ft. x, /. r) to e. hut we cannot apply push to the eonclusion 
and finish the proof because (?r2(fc,x,/,r) It) is on the left, not the right. I had elided the following detai . 
transposition is invertible on each type by (5) so x = (it, u 2 ).y =» («, « 2 ).x = ?/• push applies this as an 
intro-rule to ‘’draw transposition to the right”. With this elaboration the proof runs smoothly. 

The proof of (27) runs along similar lines. To prove (28) 6#e we unfold definitions and use nevsimp to 

obtain 

A b. c. (?n(fc,r) b).c = c. 


If c is a closed term push solves this completely (otherwise proof fails, as it should). 

(29), (30), (31), are proved hv the same script as (2G). In fact, the script also proves (2<) though its 
behaviour for that goal, the path outlined in the previous paragraph, is a little special. 

(32) underlies newname. The proof is best tailor-made. We rewrite it as 3/;. 6#x A T and intro-resolve 
against (36) for P = Afc.T, we now have 1/16. b#x, an instance of the axiom (9). 


7 The state of the implementation 

An Isabelle/FM implementation exists but it is based on set theory rather than higher-order logic. This 
creates technical difficulties which ultimately proved insurmountable for the following reason. Consider the 
theorem 

TyProd(f,,/ 2 ) = TyProd(f!,, < 2 ) => 

In HOL this is rendered as 

TyProd(lt{',ti) = TyProd(t:/,4 i ) =» t‘{ = t[ L 

where we include all type annotations. In sets the same theorem is 

TyProd(t) , /■>) = TyProd(to, t'>), ti £ L,t 2 £ L,t\ £ L.t 2 £ L => <i = h- 

The difference is that when we intro-resolve against the HOL version we get one subgoal, whereas the sets 
version produces five (one each for each hypothesis of the implication, which must he established m order to 
apply it). A sets-based treatment of inductive datatypes overcomes this by implementing TyProd by some 
constructor which is is injective on the entire sets universe “by coincidence’, probably Inr(Inl(-)). In FM 
this is not possible for various reasons which we now sketch. 

Atoms must he marked as belonging to atomic type, the Id quantifier introduces fresh variables of atomic 
type which must be marked as such, and atom-abstraction a,x i-> a.x (which we have not discussed in this 
paper, see [8, Section 6] or [6, Section 5]) is fundamentally non-injective so that the typing conditions can 

actually get quite complex. ... . 

Considerable ingenuity went into minimising the impact of these typing conditions in a sets environment 
(this should soon be the subject of a technical report). The price of using a HOL environment is precisely its 
benefit the relative rigidity the typing gives the theory relative to sets, with both theoretical and praetiea 
consequences. In t he recently-published [8] we provide what we hope is an elegant solution to the theoretical 
difficulties which will also be implement able, and it remains to try implementing the approach. 


8 Conclusions 

This paper has given a very simplified account of the problem of producing an implementation of a new 
foundational system FM with new and unfamiliar predicates and constructors. We considered two simple 
examples: 

Some theory of a datatype of types with universal types E and relations of o -equivalence for it — 0 
(defined using FM structure) and =„' (defined in a more traditional style). 

- Some technical FM lemmas (23) to (32). 

These examples illustrated a fairly rich and representative selection of problems. We presented solutions to 
these problems and discussed their limitations. Another contribution of this paper is in what it elides: there 
are complications to automating FM which this paper has tried to bring out. but the short, slick, parts in 
between are the proof of how far we have already come. 
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Abstract. This paper presents two protocols of SPIDER, a fault tolerant broadcast communication 
architecture. The Interactive Consistency Protocol (-‘Byzantine Agreement' ) takes care of reliable mes- 
sage broadcast in the presence of malicious faults. The Diagnosis Protocol distributes local information 
about the health status of nodes through the network, such that each node arrives at a correct and 
consistent classification of which nodes are faulty and which are not. Correctness here means that only 
faulty nodes are convicted. Such diagnostic information may be useful for on-lme maintenance. The 
two protocols are based on each other: Diagnosis uses the Interactive Consistency Protocol for reliable 
broadcast of accusation messages. Interactive Consistency relies on up-to-date health status informa- 
tion and produces diagnostic data. In order to formally prove that diagnosis is able to strictly improve 
reliability we define the Dynamic Maximum Fault Assumption, which depends on the set of convicted 
nodes. We provide formal proofs in PVS that given the Dynamic Maximum Fault Assumption and a 
sane health status classification, the Interactive Consistency Protocol satisfies validity and agreement, 
and that the Diagnosis Protocol provides again a sane classification and convicts all benign faulty nodes, 
all accused symmetric faulty nodes, and asymmetric faulty nodes accused by a majority of undeclared 
nodes. 


Keywords: fault tolerance. SPIDER. Byzantine, reliability, Diagnosis, Interactive Consistency. 


1 Introduction 

The Scalable Processor-Independent Design for Electromagnetic Resilience (SPIDER ) is a family of general- 
purpose fault-tolerant architectures being designed at NASA Langley Research Center to support laboratory 
investigations into various recovery strategies from transient failures caused by electromagnetic effects. The 
core of the SPIDER architect ure is the Reliable Optical Bus (ROBUS). As part, of an effort partially sponsored 
by the FAA, the ROBUS is being developed in accordance with RTCA DO-254: Design Assurance Guidance 
for Airborne Electronic Hardware. 

SPIDER is a family of communication architectures that provide reliable broadcast in the presence of 
multiple, possibly malicious ( “Byzantine”) faults (Figure 1). Various processing elements (PEs) are connected 
by the Reliable Optical Bus (ROBUS). The PEs may be computing nodes, sensors, or actuators, or composites 
of them. The ROBUS is formed by a column of N Bus Interface Units (BIUs), each connected to its PE. 
and a column of M Redundancy Management Units (RMUs). Each BIU is connected to each RMU, but 
the BIUs and RMUs are not connected to their own kind. In other words, the BIUs and the RMUs form a 
complete bipartite graph. The number of RMUs can be chosen freely; the sole purpose of the RMUs is fault 

tolerance. , , 

SPIDER comes with three protocols: the Interactive Consistency Protocol, which takes care ot reliable 

message broadcast, the Diagnosis Protocol, which arrives at a global fault classification, and the Synchroniza- 
tion Protocol, which synchronizes the clocks of all nodes. Synchronization provides a basis for us to compose 
nodes synchronously in a way similar to Rushby [4], The SPIDER architecture and these three protocols 

* This work was supported by the National Aeronautics and Space Administration under NASA Contract No. NAS1- 
97046 while the first author was in residence at ICASE, NASA Langley Research Center, Hampton, VA 23681-2199. 
USA. 
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PEs BIUs RMUs 



Fig. 1 . SPIDER architecture 


are described in more detail in [2]. Formal Verification of the first and the second protocol are complete; 
Formal Verification of the third is currently under development. A fourth protocol is being designed: the 
Readmission Protocol. Its purpose is to allow transiently faulty nodes to be reintegrated. All of the protocols 
are being verified using PVS [3]. 

In this paper we present two SPIDER protocols in detail: the Interactive Consistency Protocol and the 
Diagnosis Protocol. The PVS models for the two protocols can be found at URL 

http : / /www . icase . edu/~geser/spider/diag . dmp 

We state two essential assumptions. The first, called the Maximum Fault Assumption, ensures that the 
health status of the ROBUS is good enough for the protocols to work. The second, called the Correct Active? 
Sources Assumption, takes care that the ROBUS has a sane view of its health status. We show that under 
these two assumptions, 

- Interactive Consistency satisfies validity (the message of a good node is faithfully forwarded to all re- 
ceivers) and agreement (all receivers receive the same message); 

- Diagnosis preserves the Maximum Fault Assumption and the Correct Active Sources Assumption; 

- Diagnosis provides convictions: every declared node is declared by all good nodes; 

- Diagnosis declares all benign bad nodes, all accused symmetric bad nodes, and all asymmetric bad nodes 
accused by a good majority of undeclared nodes. 

In the design of the two protocols we take care that readmission is not impeded. For instance, some good 
nodes may be distrusted for their former bad behavior. If there shall be a chance to readmit them, the 
distrust must not go on indefinitely. We address some of the ramifications. Moreover a readmission protocol 
is dynamic by nature, i.e., it has to speak about the temporal evolution of faults and their assessment. We do 
not elaborate on this issue here. Interactive Consistency and Diagnosis are modeled as functional programs. 
A dynamic model is outside the scope of this paper. 


2 Related Work 


The protocols for the SPIDER were derived from a number af earlier architectures. The Interactive Consis- 
tency protocol was inspired by the Draper FTP [6]. The initial PVS verification of the SPIDER protocol 
was adapted from the verification of the FTP protocol performed by Lincoln and Rushby [1]. The SPIDER 
diagnosis protocol was inspired by the on-line diagnosis protocol developed for MAFT [8]. Our diagnosis 
algorithm performs the same task as Algorithm DD in that paper. The PVS formalization of this protocol is 
described by Walter, Lincoln, and Suri [9]. For the verification of the MAFT architecture, gathering of ac- 
cusations was explicitly modeled. We have separated the mechanism of fault detection from the distribution 
of the gathered fault information. Our notion of diagnosis refers to the latter. We give explicit constraints 
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on what, constitutes an accusation. Let., the claim that a node is faulty. Any accusation basis that satisfies 

those constraints may ho used. .... ^ , . , 

Tho SPIDER architecture differs from many other fault-tolerant architectures m that it is not coinple e \ 

connected. So t he BIUs have no direct observations of their own kind. This fact has fundamental ramifications. 
A BIU may only make direct accusations against RMUs. Any evidence that another BIU is faulty must come 

indirectly through the RMUs. . , c , nlnrn • rn 

Rushby presents a (comparison of four safety-critical bus architectures, including SPIDER, in [oj. 


3 Basic Types and Properties 

3.1 Node Types and Symmetries 

In the ROBUS architecture. BIUs and RMUs are somewhat symmetric to each other. This symmetry is not 
perfect since, e.g., BIUs are connected to PEs and RMUs are not. However it is tempting, and rewarding. 

to exploit, in PYS the symmetries present. _ f 

The BIUs and the RMUs arc instances of node types. Node types are modeled as types, below (h). ° 
integers in the range 0..A' - 1. On this account a node type is represented uniquely by its positive, finite 
cardinality, K. PYS theories may now be parameterized by node type cardinalities, which may he instantiated 
by N for the BIUs or by M for the RMUs. Sometimes we provide two parameters, L and R. for the node 
types LEFT and RIGHT, which tnav be instantiated by N and A/, respectively, or by M and A . respectively. 
If the theory thus parameterized describes a protocol then the two instantiations mean usage of the protocol 
in two symmetric ways. 


3.2 Hybrid Fault Types 

Faults mav he classified according to the potential consequences they may cause. Our approach is to assume 
that arbitrary. Byzantine faults may exist, but that they are rare and that less malicious faults come in 
greater numbers. We distinguish the following hybrid fault types, introduced in [7], that a node can exhibit: 

- A good node behaves according t.o specification. 

- A benign faulty node only sends messages that are detectably faulty (this includes nodes that have 
failed silent). 

- A symmetric faulty node may send arbitrary messages, but does so the same way to each receiver. 

- An asymmetric faulty node may send arbitrary messages that even may differ for the various receivers. 

A node that is not good is called bad or faulty. The three bad hybrid fault types form a hierarchy in the 
sense that ail asymmetric node has all capabilities of a symmetric node, and a symmetric node may behave 

like a benign node. . „ , 

In view of readmission, we further split good nodes into trustworthy nodes and recovering nodes. Both 

behave perfectly identical but the trustworthy nodes must moreover be trusted whereas the recovering nodes 
need not. The trustworthy nodes are the good ones that we can count on. Without readmission, all good 
nodes are trustworthy. With readmission, we may have a node that changes its fault status from benign to 
good. For various reasons SPIDER cannot figure out instantaneously that, the node has changed. So there is 
some time interval where the node is already good but SPIDER has not yet noticed it. We let the node be 
recovering for some specified time to allow SPIDER to reset its trust in this node. 

The sets of trustworthy, recovering, benign, symmetric, and asymmetric BIUs are denoted by 1 B. KB. 
BB. SB. AB. respectively. Likewise TR. RR, BR, SR. AR for the RMUs. 


3.3 The Model of Communication 

Data received by a node are of type robus-data[T] where the parameter T denotes the type of data to be 
communicated. The type robus.data[T] comprises 


- valid data of type T . 
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receive error, a token that expresses the fact that an error has been detected during reception, 

- source error, 

- no majority. 

Note that the absence of an expected message can be detected, so a missing message is modeled by 
receive .error . The purpose of the tokens source -error and no, majority will be explained in the Interac- 
tive Consistency protocol below. 

The behavior of a transmission line from LEFT node p to RIGHT node r, with data d to be sent, is 
modeled as a function send in PYS as follows: 

send (status) (p, <7, r) : mbits -data [T] = 

CASES status (p) OF 
trustworthy : d, 
recovering : d, 
benign : receive, error, 
symmetric : sym_send(p, d), 
asymmetric : asymsend(p,d, r) 

ENDCASES 

status represents the global fault assignment to nodes, which during this discourse remains unchanged. We 
will henceforth suppress all status parameters in favor of a concise representation. As send must not use any 
information available to the hardware, we let send have no parameters that allow to deduce such information. 
Conversely, as we will set 1 below, the hardware must not have any access to the fault status. 

The value d is of type robus .data[T] rather than type T. This accounts for values that an 1 relayed and 
may so be non- valid at p even before transmission. A benign node acts in such a way that a detectable error 
results at the receiver side. As we are not interested in the kind of error, we simply record the fact of the 
reception error. Tin 1 behavior of a symmetric node is modeled by an uninterpreted function symsend. By 
the definition of type robus-data[T], the value of symsend(p, d) must be some of valid (d 1 ), receive. error, 
source-error , no. majority for some d! : T. As we do not specify which it is, we have to cope with an arbitrary 
function symsend which is constrained only by its parameters. The parameter d expresses the potential to 
send valid(d), i.e., to fake good behavior. The parameter p expresses the potential that each symmetric node 
may exhibit individual behavior. The symmetric behavior follows from the fact that r is not a parameter 
of syrn.send(p.d). For the asymmetric nodes we have a similar uninterpreted function asym send which 
moreover has the parameter r and so the potential to exhibit asymmetric behavior. 


3.4 How Faulty Node Behavior is Modeled 

Bad behavior of a node is only observable through its communication. This gives us an extraordinary capa- 
bility. We may rightfully pretend that a bad node works like a good node, and that all faulty behavior is due 
to the communication lines between nodes. Therefore we may speak about the state of a node as if it were 
a good node. And we may assume that, each node sends correct values. Only upon reception does the had 
character show up. We use this convenient view throughout the presentation. 

3.5 Local Fault Classification 

Each good node maintains a view of the health of all nodes. A node obs (the observer), may classify a node. 
def (the defendant ), as being 

- trusted, if obs has no evidence of def being faulty; 

- accused, if obs knows that def is faulty but is uncertain whether this knowledge is shared by other good 
observers; 

declared, if obs knows that def is faulty and every good observer of the same kind also dec lares def . 

The local fault classification forms a hierarchy of increasing knowledge 1 of obs about def . Sometimes we will 
need to merge knowledge arriving from two sources; in this case we will get the maximum, w.r.t. the order 
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trusted < accused < declared, of flit' arrived values. For instance, merge (trusted, declared) - declared and 
merge. ( declared . accused) — declared. 

We call the map net that assigns each pair of nodes, obs and def. a fault classification, ac.t.(obs)(def). 
the active-sources matrix of the ROBUS. More precisely, there is an active sources matrix for each pair of 
node types of observer and defendant. The value act{obs){def) is what obs takes def for m the current state. 
The row act(obs) of the active source's matrix is called the active sources vector of obs. Note that, its active 
sources vector is all that, obs knows about the health status of the ROBUS. The following three properties 
are required for active sources vectors, actv: 


- good trusting: every good node is trusted. 

- symmetric agreement: every noil-asymmetric node is assessed the same way by two observers 

- declaration agreement.: the set of declared nodes is the same for any two observers. 


The three conditions are rendered in PYS as follows: 

good .trusting! (actv) : bool = V def : good'!(def) => trusted'! (actv (def)) 
symmetric -agreement.'! ( actv [. actv 2) : bool = Vde/ : -'asymmetric ! (def ) => 

(trusted'! (actv 1 (def )) O- trusted'! (ac.tv-2(def ))) 

declaration. agreement'! ( actv \ . actv 2 ) : bool = Vdef : declared'! ( actv , ( def ) ) declared'! (actv 2 (de/)) 

The conditions good .trusting! and declaration. agreement.'! are clearly motivated by our definitions of 
accused'! and declared'!. We will demonstrate in Example 2 that, symmetric .agreement'! is an essential premise 
to correctness of the Interactive Consistency Protocol. 

In a new born ROBUS. no node has any evidence of faulty nodes whatsoever. Hence every node trusts 
every node. It is easy to verify that ('very row in this active sources matrix satisfies good .trusting ! , and e\ er\ 
pair of rows satisfies symmetric -agreement! and declaration -agreement . . 

During the Diagnosis Protocol, active sources vectors are merged with new evidence, which is also rep- 
resented as an active sources vector. The merge function is lifted to active sources vectors by 

merge. active ( actv 1 . actv-i) '■ active. vector. type[N] = A def : merge.(actv x (def), art« 2 (dc/)). 


3.6 Message Qualities 

For the proofs it will be convenient to speak about the following properties a message may have. A data 
vector may satisfy 

— good message: a good node is assigned a valid message. 

— benign message: a benign node is assigned receive -error . 

— benign source: a benign node is assigned source -error. 

— good vote for: all good nodes are assigned the same given message. 

In PVS this is expressed by 

good -message! (dv) : bool = VC : good?(G) =$• valid?{dv(G)) 
benigTi -message! {dv ) : bool — \fG : benign ?(G) ^ receive -crroi ,{dv{G)) 
benign source! {dv) : bool — VC : benign! {G) source -en or. (di (G)) 

good -vote -f or! {dv,d) : bool - VG : good!{G) => dv{G) = d 

1 in view of the next property, it is sufficient to require that observers trust the same sets of non-asym metric nodes. 
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3.7 Accusation Vectors 


During the Diagnosis Protocol, messages are transmitted that carry information about the sender's classifi- 
cations of other nodes. Usually only a certain aspect of the classification is wanted. 

An accusation vector is a function from nodes to accusations , i.e.. the values working or failed. Accusation 
vectors are sent across the ROBUS to inform other nodes about some aspects of the local active source's 
vector. To this end wo provide two functions in PVS, one for encoding {form) and one for decoding {extract). 
For the purposes of accusation exchange, we encode the information whether a node is trusted. For the 
purposes of declaration exchange, we encode whether a node is declared: 

form.accvee{aetv){p) : accusation = IF trusted'- ( actvfp)) THEN working 

ELSIF accused'! (actv{p)) THEN failed 
ELSE any -accusation ( actv . p) ENDIF, 

extract -accvec{aeev)(p) : trust - IF working! (accv(p)) THEN trusted ELSE accused ENDIF. 
form _ decvec(actv) (p) : accusation = IF declared'? (actv{p)) THEN failed ELSE working ENDIF. 
extract -decree {accv){p) : trust — IF working ?{accv{p)) THEN trusted ELSE declared ENDIF 

In the design of form.accvec we leave deliberately open how declarations are translated. This is achieved 
by the uninterpreted function any .accusation . In the current SPIDER implementation we took the choice 
any-accusation{actv,p) = working. It is routine to prove a few lemmas that relate properties of accusation 
vectors to properties of active sources vectors. 


3.8 The Maximum Fault Assumption 

The purpose of the Maximum Fault Assumption is to both (1) hold with specified probability and (2) provide 
a basis to conclude correct operation of the SPIDER protocols. In the absence of diagnosis, the Maximum 
Fault Assumption is independent on the local knowledge of the health status of the system. SPIDER does 
not tolerate a simultaneous asymmetric fault of both a BIU and an RMU. Moreover we need a majority of 
trustworthy nodes of each kind. So the Maximum Fault Assumption is defined by: 

1. \TB\ > \SB\ + \AB\i and 

2. |T7?| > | Si? | + and 

3. \AB\ — 0 or \AR\ = 0. 

This Maximum Fault Assumption does not improve by diagnosis, i.e., if diagnosis is able to declare new nodes 
then this has no impact on the Maximum Fault Assumption. Hence there is no formal proof that, diagnosis 
has any positive effect. But there is a meta-level proof: assume that a node becomes benign when declared. 
Then declaring a symmetric or asymmetric node increases the majority of the good nodes, arid declaring an 
asymmetric node may deplete the set of asymmetric nodes of its kind. This meta-level construction, however, 
does not allow readmission of transiently faulty nodes: a node that, is diagnosed stays benign forever. 

To enable readmission we introduce a weaker assumption that we call the Dynamic Maximum Fault 
Assumption. It has an additional parameter, U, for the set of nodes that some node does not declare. The 
Dynamic Maximum Fault Assumption is defined by: 

1. \TB\ > | SB n U\ + \AB fl 1% and 

2. \TR\>\SRnU\ + \AR.nUl and 

3. j AB n U | = 0 or \AR fl U | = 0. 

Note that diagnosis improves the Dynamic Maximum Fault Assumption. As more nodes are declared, V gets 
smaller, and so it is easier to have a majority of good nodes among U . or to exclude* asymmetric nodes from 
U. Our hope is that diagnosis will particularly aid in the latter. 
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4 An Informal Overview 


4.1 The Interactive Consistency Protocol 


A message broadcast protocol is called reliable if it satisfies the following two properties: 


- validity: every good node receives the value sent by a good node. 

— agreement: all good nodes agree in the value sent. 


For reliable message passing in the presence of various faults, we use the Interactive Consistency Protocol. 
We present the protocol parameterized by two node types, LEFT and RIGHT, that may be instantiated by 
the types of Bit's and RMUs, respectively, or by the types of RMUs and Bits, respectively. For reliable 
message broadcast among the PEs, we need the former instance. Indeed, in the Diagnosis Protocol we will 
need both symmetric instances. The Interactive Consistency Protocol works as follows: 


1. A single LEFT node, g. as per agreed schedule, broadcasts some value, valid (v). to all RIGHT node's. 

2. Every RIGHT node relays its received value, d, to all LEFT nodes. However, if d = receive .error then 
it sends source, .erroi to redirect the blame from itself to the originator of the message . 

3. Every LEFT node, p, collects tin' vector of values it received (one value per RIGHT node). Then it 
determines the set of RIGHT nodes it trusts. A RIGHT node from which p receives receive. error is 
accused by p. These classifications are merged with p s Active Sources Vector. 

4. Else if p receives some value d ma j from a majority of trusted RIGHT nodes then it determines d mnj and. 
if d m „, is non- valid, declares g. Otherwise p determines no .majority and declares g. 

5. If LEFT g is declared by p (not including the recent declarations in Step 4) then p forwards source .error 
to its PE. Otherwise p forwards the value determined in Step 4 to its PE. 


We will refer to Step 1 as a single source broadcast and to Steps 2 to 4 as a consistent source exchange. 
Consistent source exchange will turn out useful outside the Interactive Consistency Protocol. 



Fig. 2. Two counterexamples: Step 5 is essential for agreement (RMU 2 is asymmetric; see Example 1) and the 
Symmetric Agreement premise is essential for agreement (RMU 2 is symmetric; see Example 2) 


In a previous version of the Interactive Consistency Protocol, in Step 2 a relay turned d into source. error 
also in the case where it received a correct value but did not trust, the general G. Although this is undeniably 
correct, it is undesirable in view of readmission because a declared nodi' has no chance to prove it is good 

again. . 

Step 5 is introduced to ensure agreement under the weaker Dynamic Maximum Fault Assumption. A 

version that skips Step 5 and rather forwards the value determined in Step 4 to the PEs, may violate 
agreement under the Dynamic Maximum Fault Assumption: 

Example 1. Let M = N = 3 (Figure 2). Suppose that BIU 1 is asymmetric, but declared: the Dynamic 
Maximum Fault Assumption allows the existence of asymmetric, undeclared RMUs. Now let BIT 1 send 
valtd(v) to the good RMU 1 and to the asymmetric RMU 2, and a different valid(v') to the good RMU 3. 
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Let Bill 2 trust all RMUs. and ltd BIU 3 trust RMUs 1 and 3 only. Then BIU 2 finds a majority value, 
valid (v), whereas BIU 3 finds no majority. So the old Interactive Consistency Protocol does not satisfy 
agreement, for the Dynamic Maximum Fault Assumption. 

A similar example shows that the symvietric .agreement'? premise is essential: 

Example 2. Lot, hi = A = 3. Suppose that BIU 1 is asymmetric and the static Maximum Fault Assumption 
holds. Now let BIU 1 send valid (v) to the good RMU 1 and to the symmetric RMU 2. and a different valid (E) 
to the good RMl 3. Ltd BIU 2 trust all RMUs, and ltd. BIL 3 trust RMUs 1 and 3 only. So symmetric 
agreement does not hold. Then BIU 2 finds a majority value, valid (r), whereas BIU 3 finds no majority. So 
agreement, is violated. 

4.2 On the Collection of Evidence 

During all protocols each node records evidence of faulty behavior of other nodes that it learns through 
communication. Sonne of this evidence ma\’ lead to an accusation of a node. Some* evidence, for instance a 
non-valid result of an Interactive Consistency exchange, may even lead to a declaration of the general by 
virtue of the agreement property. 

We distinguish between direct and indirect observations that lead to accusations against nodes. A direct 
observation is a single event that may lead to the accusation of the sender. Direct observations are: 

— No message was received during the reception window; 

- An improperly formatted message is received. 

These observations take place during all protocols. “Improperly formatted” may also mean that an encoded 
message does not pass the parity check. The effect of a direct observation is modeled by the receive .error 
token. 

Indirect observations an 1 a collection of events that together provide the basis of an accusation. This 
involves a majority vote. They come in two kinds: either a node of the same kind, or a node of the other 
kind is accused. Let the diagnosing node be a LEFT node. 

1. a majority of RIGHT nodes offer evidence against a LEFT node; that LEFT node is accused. 

2. in a consistent source exchange, a RIGHT node disagrees with the majority; this node is accused. 

3. in an Interactive Consistency exchange from the LEFT, there is no majority: then the general is accused. 

4. in a majority of Interactive Consistency exchanges from the LEFT, a RIGHT relay disagrees with the 
majority; this relay is accused. 

By the agreement property, an accusation of the Form 3 is made by all LEFT observers, so they may issue a 
declaration. We conjecture that, likewise, an accusation of Form 1 can be turned into a declaration. A typical 
case is the declaration of a general of an Interactive* Consistency exchange on the basis that a majority of 
trusted RIGHT nodes vote for source-error. All of those indirect observation mechanisms are* in place in the 
current SPIDER implementation. 

4.3 The Diagnosis Protocol 

The purpose of the SPIDER Diagnosis Protocol is to distribute the local accusations in order to arrive at a 
consistent classification of the health status of the ROBUS. It does that by merging the active sources vectors 
with new declarations. By the bipartite ROBLS architecture, agreement among all nodes cannot be reached 
in one sweep. Rather, agreement among nodes of the same kind is achieved first, i.e.. we get declarations. 
This step is called the accusation exchange. Agreement among nodes of opposite kind is ac hieved in the 
second sweep, the declaration exchange. 

The Diagnosis Protocol shall preserve good -trusting? , symmetric .agreement'? , and declaration, agreement'? . 
By the fact that classifications are merged, the Maximum Fault Assumption is also preserved. We require 
moreover that the Diagnosis Protocol establishes the following properties: 

- conviction agreement: every declared node is convicted, i.e., it is declared by both kinds of nodes. 
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- benign declaring: every benign node is declared. 

- symmetric declaring: every symmetric node that is accused by a good node is declaied. 

- majority declaring: if « set of good LEFT nodes that forms a majority among the undeclared and 
non-henign LEFT nodes accuses a node then that node is declared. Likewise for RIGHT nodes. 

The properties are rendered in P\ S as follows: 

convictio7i-ayreemerit'?(actii, actir) : bool — 

V</, r : good‘!(q) k good'!(r) => d(TAaiution-agreemnd?(aciti(q). acti r (r)). 
bejiign.dcclaringfiactVd) : bool = We/ : benign! (def) => declared'! (actv (def )) 
symmetric -declaring'! (actv , actvw>) : boo! = 

M def : accused'! {actv u\ (def)) k symmetric !(dcf) declared . {actv ^{def )) 

majority -declarin(j'!(uctvi\. actv ( t\, actv £>) : bool = 

We/ : ^working! (rnajority (undeclared ( actv ^ ) \ fceru^u, working . 

solid(forrn-accvcc(XG : urTrv/ (G)( def ) ) ) )) 

=> declared'! I actd 2 ( de/ ) ) 


where the auxiliary function solid is defined by 

«oKd(accv)(G) : acru.sattor* = IF good‘!(G) THEN acrv(G) ELSE working ENDIF 


The operator \ denotes set difference. 

The requirements are motivated as follows, conviction -agreement'! expresses the maximal distribution of 
declarations: every node arrives at the same set. Of course we want to declare as many bad nodes as possible: 
all benign nodes, all symmetric nodes accused by a good node, and some asymmetric' nodes. Example 3 below 
shows that in the property majority .declaring '! . it is essential that the accusing nodes that, are in the majority 
are good. In other words, it is essential that the accusing nodes that form a majority are good, solid(accv) 
denotes the set of accusations in accv that cannot be shattered. 

The Diagnosis Protocol works as follows: 


1. 

2 . 

3. 

4. 


BIUs reliably exchange their accusations. If a majority of undeclared BILs accuse a node then that node 


is declared. 

RMUs reliably exchange 


their accusations. If a majority of undeclared RMUs accuse a node them that 


node is declared. 

BIUs broadcast their declarations to the RMUs; the RMUs merge these with their declarations. 
RMUs broadcast their declarations to the BIUs; the BIUs merge these with their declarations. 


We exploit the obvious symmetry by providing an accusation exchange protocol arid a declaration exchange 
protocol, each parameterized wit b LEFT and RIGHT. 

The accusation exchange* protocol works as follows: 

1. each LEFT node, G, uses the Interactive Consistency Protocol to broadcast, to all LEFTs, its vector of 
accusations against any node. 

2. after Step 1. each LEFT node, has collected a vector of received values (one value per general G). 

3. LEFT nodes from which p received source-error are declared by p. 

4. If a majority of (then) undeclared LEFT nodes accuse a node then that node is declared. 


The declaration exchange 1 protocol w r orks as follows: 

1. by a consistent source exchange, each RIGHT node, r, broadcasts its declaration vector to all LEFT 
nodes. 

2. each LEFT node, p. merges the received declarations with its own active sources vector. 

The following counterexample shows that a majority of undeclared accusers may or may not lead to the 
declaration of a node. If a had accuser is tossed out of the set of undeclared nodes then the majority may get 
lost. Even worse, the opposite of its vote may be received. In other words, for property majority -declaring! 
it must he good nodes that form the majority. 
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r.e. = receive .error 


Fig. 3. A majority that is supported by a symmetric node (see Example 3) 


Example 3. Let M = N ~ 3 (Figure 3). Suppose that BIU 1 is symmetric, that BIUs 2 and 3 are good, and 
that BIUs have no declarations against each other. Next suppose that RMU 1 is asymmetric and trusted 
by the BIUs. We do not care about the other RMUs. Now let the BIUs receive receive. error, valid (v), and 
receive. error, respectively, from RMU 1 during some Interactive Consistency exchange. This has the BIUs 
2 and 3 accuse RMU 1. We now show that RMU 1 is declared if and only if BIU 1 is not excluded from the 
vote of the BIUs. If the RMUs receive receive. error from BIU 1, then they forward source.error to all BIUs. 
so all good BIUs declare BIU 1. But then the number of votes (one) that accuse RMU 1 is not sufficient, 
to form a majority in the set {BIU 2, BIU 3}. So RMU 1 is not declared. However if the RMUs receive a 
correct accusation vector from BIU 1 then the number of votes (two) is sufficient for a majority in the set of 
all BIUs, and RMU 1 is declared. 

Example 3 witnesses the strange fact that diagnosis may profit from a faulty node (BIU 1) going unde- 
tected. 


5 The Formal Model 

The following description is intended to aid the reader in understanding the PVS proofs. 


5.1 Majority Votes 

Suppose that every LEFT node presents a value to our receiving node. These values form a value vector. 
vv. The set of voters for a value v is defined by {i | vv(i) — ?;}. Some voters can be excluded from the vote 
by a filter set H ; only votes of members of H are counted. Now v is in the majority among H in vv, if 
2 | H n {i I vv(i) = v}\ > |//j. The function majority (H, default, vv) yields this unique majority value v if it 
exists, otherwise it yields the default value, default . Two value vectors are called H- similar if they agree for 
nodes that are in H, Formally: 

similar .vector'? [H, vv\ , vv->) : bool = V?' : H(i) => vv x (i) = vv^ij) 

The outcome of the vote agrees for similar vectors: 

Lemma 1 (Majority unique). 


similar. vector !( H, vv { , vv 2 ) h majority (H, default, vv\) = majority (H, default, vv 2 ) 


If the good nodes (of one kind) agree, then the value they vote will be the majority value: 
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Lemma 2 (Good vote for majority). 

hybrid -majority -good ? ( H ) . hyb rid. select ? (H). 
good .vote -for? (vv. v) 

h 

majority (H , default, vv) = v 

There is one variant of Lemma 2 per node kind. For the BIUs, hybrid. majority. good! (H) stands for \TD\ > 
\SBr\H\ + \ABC\H\: hybrid. select.'! (H) denotes that TB C H and BB(~)H — (/I. The two properties together 
ensure that 2 | TBD H\ > \H\. i.e.. the good are in the majority among H. Since the set of good nodes is a 
subset of the set of nodes that vote for r, the value v will be the ma jority value. 


5.2 Consistent Source Exchange 

In view of their role in the Interactive Consistency Protocol, we call the transmitters in a consistent source 
exchange relays . 

Suppose that dv denotes the vector of values sent by the relays. The function relay. data, defined by 

relay -data(dv)(r){G) : robus .data[T] = input .filter (send(G,dv(G),r)), 

describes the values received at r and preproccssed by input, -filter. The preprocessing replaces all unexpected 
message formats, such as no .majority or source. error, by receive. error. The function elim .relays (dv. actv,) 
merges actv ,, the active sources vector of the receiver, with the fresh evidence obtained from the received 
data vector dv: a node from which receive. error was received is accused. The function vote, defined by 

vote(dv, actvi) : robus. data[T\ = majority (trusted ( dim. relays (dv, actv ;)). no. majority ,dv), 

yields the majority value among the trusted nodes if it exists, and no. majority else. The consistent source 
exchange is modeled in PVS as a function 

csx(dv. acti)(r) : robus -data[T] = vote{relay.data(dv)(r), actvi) 

The following theorem assumes that a RIGHT node, r, trusts all good nodes; every good LEFT node 
G sends a valid message dv(G): all good nodes send the same value d\ the set of trusted nodes has greater 
cardinality than the? set of symmetric or asymmetric nodes. It says that then r determines the value d. The 
active sources vector of r is denoted by actvi. The vector of data that the LEFT nodes send is given by dv. 
We will abbreviate elim. relays {relay -datQ{dv)(r), actv i) by elim -CSX -relay s(dv, actv i){r). 

Theorem 1 (Validity of consistent source exchange). 

goo(Ltrustmg?(actvi), good . message? (dv), good.vote-for ? .{dv. d). 
hybrid -majority -good? ( trusted ( elim .csx .relays (dv, actvi)(r))), 
h 

csx(dv, actvi)(r) — d 

Proof, relay. data has the property benign .message? and preserves the pair of properties good. message . 
and good .vote -for?. Next trusted(elivi-csx. relay s{dv, actvi)(r)) satisfies hybrid .select? . Lemma 2 finishes 

the proof. 

The following lemma is crucial for the agreement theorem below. It states that, if two right nodes trust 
no asymmetric left node; trust the same symmetric left nodes: and receive the same data vectors, up to data 
from non-trusted relays, then they will finally trust the same left nodes. 
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Lemma 3 (Trusted agreement). 

no, asymmetric !(trusted(actv n )). no-asy7nmetric'?(t7'usted(actvi 2 )). ( 1) 

symrnetnc. agreement'! (actv f] . actvf 2 ), similar .vector ! ( trusted (actvn ), dv x . r/r 2 ). 

I- 

trust ed(elim. relay s (dv \ . actvn)) — trusted ( elirn. relays ( dv 2 . actvio)) 

Proof. Let x be a node. We prove that x is trusted by the active sources vector dim .relays (dv x , acton ) iff* is 
trusted by elmi. relay s(dv i , actv l2 ). If * is asymmetric then by (1), * is trusted neither by actvn nor by ac.tv , 2 . 
Because elim .relays (dv x . actv f ) trusts less nodes than actvf for all acton we get the claim. So let * be non- 
asymmetric. Then by symmetric: agreement, actv n (x) ~ actvlx). If ac.tv n trusts *, then dv x (x) = dv 2 (x) 
because dv x ,dv 2 are trusted (acdii)-shml’dr. It turns out that then the relays disqualified by dri.dvy arc' the 
same. Finally, if ac.tv n does not trust *, neither dim. relays {dv \ , actvn ) nor elim .relays (dv \,actv( 2 ) trusts 
x. 

Theorem 2 (Agreement of consistent source exchange). 

good .trusting! ( actvi i ), good, trusting'! (actvi •> ) , 
symmetric. agreement? (actv i \ , actvi 2 ), good _ message ? ( dv ) , 

no. asymmetric! (trusted(actvn)) k no. asymmetric !( trusted (actv r2 )) OR (2) 

good, vote ,f or? (dv) k hybrid. majority. good? ( trusted (eli7n.csx-relatjs(di\ actv n )(r \ ))) k (3) 
hybrid, majority, good 1 ! ( trusted( elim.csx, relays (dv, ac.tv {2 ) (r 2 ) ) ), (4) 

h 

csx ( dv , ac tv 1 1 ) ( r 1 ) = csx (di\ a ctv \ 2 ) ( r 2 ) 

Proof. By case analysis. If (2) then the vectors received by any two RIGHT nodes are similar. Lemma 3 
establishes that the sets of trusted nodes agree for n and r 2 . Hence n and r 2 will arrive at the same result 
of the voting. If rather (3) and (4) hold, then csx(dv, actv n )(r l ) = dv(p) = csx(dv, actv r >)(r 2 ) for some good 
LEFT p by two applications of Theorem 1. 

For curiosity we mention the remarkable fact that only the most up-to-date set of trusted nodes, 
elim.csx .relays (dv, actv f )(r), needs to satisfy the hybrid. majority .good'! property. This is the best behavior 
one may ask for. However in favor of a simple approach we will replace this premise to the more conservative 
hybrid. majority .good'! (trusted ( actvi ) ) ) . 


5.3 Single Source Broadcast and Interactive Consistency 

Single source broadcast is modeled in PYS as a function 

source _data(d,G)(r) : robus ,data[T] = source.filter(input.filter(send(G,d,r))) 

where source .filter replaces receive.error by source .error and leaves all other messages unchanged. We will 
refer to the sender, G, of the broadcast as the general. 

The Interactive Consistency Protocol is then summarized in the function 

hom(act, actv r ,G , t\p) : robus ,data[T] = 

IF declared'! (act) THEN source, error ELSE csx (source ,data(valid (v), G), actv r )(p) EX DIF 

We will abbreviate elim.csx .relay s (source. data(valid(v), G), actv r ,p) by elimJc .relays (actv r , G, v,p). Inter- 
active Consistency satisfies Validity and Agreement: 
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Theorem 3 (Validity of Interactive Consistency). 

hybrid .majority -good"! ( trusted ( dim. ic .relays ( actv , .G. c, }>)))■ 
good .trusting! ( actv,). 

-i asymmctric(G ) , -‘declared'! (act) 
h 

horn (uct, actv r ,G,v,p) = source. data(valid(c),G) 


Proof. Each RIGHT node will get the same message, source. data(mlid(v).G,r). since the general, 6. is not 
asymmetric. So all good RIGHT nodes vote for this message'. Moreover source-data satisfies benign. source . 
and preserves good. message! . The 1 claim follows by Theoiem 1. 


Theorem 4 (Agreement of Interactive Consistency). 


no .asymmetric! (trusted) actv ri )) k no. asymmetric! (trustcd(actv ,••_>)) OR 

declared'! (act\) OR 
-i as ym m etri c ( G ) & 

, G. v,p \ ))) & 

hybrid .majority -good*! ( trusted ( dim Ac .relays ( actv r2 , G , v.pi ) ) ) . 
good - trusting* ! ( actv r i ) , good -trusting !(actv r2 ) : 
s y rn metric- agveem cut ! (actv r \ . a c t v r2 ) i 
declared 4 ! (act i) = declared'! (act 2 ) 


h 

hom(act\ , actv r \ <G,v,p\) — horn ( act 2 , actv r2 *G. v.p 2 ) 

Proof. If the general, G , is declared by p\ or by p 2 then it is declared by each. So /wm( acf 1 . actv r 1 • G, ? - pi ) — 

source-error = /iom(aci 2 - ac£?> r2 .(7, t%p 2 ). ^ * c 

If G is not asymmetric, each RIGHT node will get the same message, source. data ( valid ( r . G . r ) . bo 
all good RIGHT nodes vote for this message. Moreover source-data satisfies benign source! and preserves 
good-message!. By Theorem 2 the claim follows. 

As corollaries from Theorem 3 we get that the value sent by good nodes is indeed forwarded by all LEFTs 
to their PEs; somce.error is forwarded if the general is benign: and the same value, sym .send (g, volt (»’)). 
is forwarded if the general is undeclared and symmetric. 


5.4 Accusation Exchange 

Accusation Exchange is split into two parts: the reliable passing of accusation messages, and their voting 
The following PVS function provides accusation message passing: 

mxfer{act.u. act,;, act d i)(p)(G) : robus.data[accusat.ion. vector. type[D ]] = 
hom(acti,(p){G),act r i(p))(G,form.accvec(act d i(G)).p) 


Here every general. G, uses the Interactive Consistency Protocol to communicate its accusation vector to 
every receiver, p. The accusation vector is formed from G's active sources vector, act d ,(G). The receiver 
node uses its active sources vector, act rl (p), to identify the trusted relays, and the trust value act u (p)(G). 
to decide whether G is declared. 

The received accusation vectors are then processed as follows. First the received vector of messages, one 
message per LEFT node, is unpacked by unpack. ve.c, defined by 


unpack .vec(v) : accusation. vector .typc[D] — 

IF valid(v) THEN value(v) ELSE any .accusation^) ENDIF 



84 


Alfons Geser and Paul S. Minor 


If v is a valid message then its value, ail accusation vector, can he extracted faithfully. Else we return an 
arbitrary value by the uninterpreted function any _ acc usati o n ( v ) : accusatum. vector. type\D\. A node can 
d(‘clare a source from which it receives a non- valid message: 

disqualified sources (dv) : active .vector. type[L] = 

\G : IF valid (dv(G)) THEN trusted ELSE declared ENDIF 

This declaration set is merged with the active sources vector of the receiver: 

dim .disqualified (dv, actvt) : active. vector. type[L] = 
merge -active ( disqualified. sources ( dv ) , actv i ) 

The accusation vectors obtained from the undeclared sources form what we (‘all the receivers accusation 
matr iz. A iow being the accusation vector received from a node (the accuser) . the columns form the vectors 
of accusations against a node (the defendant). For each, defendant, def . the receiver does a majority vote on 
the column of the accusation matrix. Only the votes of undeclared nodes are counted. 

court ( actv i,dv) : accusation. vector .typc\D] = 

A def : majority ( undeclared {actv f ), working )(XG : unpack sec ( dv ((?))( def ) ) 

The default value of the majority vote is working , in order to implement the principle “not. guilty until 
proven guilty . The full voting complex of the accusation exchange is modeled as 

accx(dv, actv i , actv d ) : active .vector -type[D] — 
merge. active(extract.decvec(couri( elan, disqualified (dv, actv { ) , dv)) , act,Vd ) 

The complete accusation exchange is the composition of the transmission with the processing primitive: 

accx -combo (act n, act. ri, act <n)(p) : active -vector -type[D] = 
accx ( mxfer ( actu , act rh act dl )(p), act u (p), act d( (p)) 

Lnder reasonable assumptions, accusation exchange satisfies good .trusting ? , symmetric -agreement'* . and 
declaration .agreement'?. To reduce technical clutter it is useful to split the proofs into lemmas about the 
components, accx and mxfer . We render here only the most involved proof of the three: 

Theorem 5. 


hybrid -majority -good? (undeclared ( elan -disqualified (dv, actvf ) ) ) , 
good -trusting'? ( actv d ) , good -trusting'? (actv / ) , 
good -message 7 (dv), benign source? (dv ) , accusation-message? (dv) 
h 

good - trus ting ? ( accx ( dv , actvf , act v d ) ) 

Proof From the premises good -message? (dv), benign source? (dv), and good -trusting? ( actv /), the property 
hybrid select? (undeclared (ehm -disqualified (dv, actv {))) follows. By the definitions of merge-active and of 
extract -deevee, we have to prove that court associates working to each good defendant, def . So let def 
be a good node. We have to show that no majority of undeclared sources accuses def. By the premise 
accusation -message? (dv) , all good LEFT nodes agree in that def is working. By Lemma 2 the claim follows. 

Given hybrid -majority .good? ( tested ( act H (p) ) ) , good -trusting? (actu (p)), good .trusting? (act rf (p) ) , and 
good?(G ), the result of mxfer satisfies good -message? , benign source? , and accusation .message? . So we rnav 
conclude: 


A Formal Correctness Proof of the SPIDEI? Diagnosis Protocol 


85 


Theorem 6. 

hybrid .majority .good'! (undeclared(elini-disqualified (dr . actn(p)))). 

hybrid -majority -good! ( trusted ( act ,i (p ) ) ) . 
good -trusting' ?( ar.t, d i (p)), good -trusting'! ( act,, (/>)) 
h 

good -trusting*! (accx -combo (act 1 1 . act r i,actv (i} )(p)) 


5.5 Like Accusation Exchange 


The exchange of accusation against unlike nodes is exactly what we 
tion against like nodes has the additional Step 3. We model it by a 
the new evidence. 


have just sketched. Exchange of accusa- 
inerge of the accusation exchange with 


accx -combo dike ( actu , act r ()(p) • active -vcctoi' -ty. 

mejye-artive{maye-activc(disq-covib<){actii, act r i , nc£/f)(p), 

disq. combo {act u , act r j , act r /)(p)), 
nccx’_com6^(acf//, act r i . eic£//)(p)) 

The active sources vector disq.combo(ac.tn, act rl , actu)(p) expresses the declarations uttmed against the 
generals from which source-error was received during the accusation exchange against LEFT (i .e hkO 
nodes Similar declarations can be made during the accusation exchange against RIGHT nodes, jic.l R 
disq-comboiactu , «cfw «cf,,)(p). The two active sources vectors are merged to the accx .combo result. 

It is straightforward to show that this merge preserves all properties claimed for accx. combo. So tl . 
properties also hold for accx .combo .like . 


5.6 Declaration Exchange 

The reliable transfer of the declarations to the opposite kind of nodes is done by a consistent source exchange. 
Each node, G, sends its vector of declarations against, defendant nodes to all unlike nodes, r. 

declxfer(ac.t dh acti T )(r) : robus -dat,a[accusation .vector .type[D}] = 
csx{XG : valid(form-decvec(actdi(G))),actir{r))(r) 

Theorems 1 and 2 provide validity and agreement of declxfer. The received message, d. containing a decla- 
ration vector, is unpacked and merged with the local active sources vector. 

get-convictions(d. actv d ) : active. vector .type[D] = 

merge. active{extract.dec.vec{unpack.ve.c.(d)), actv d ) 

It is easy to prove that the properties symmetric .agreement'!, declaration .agreement'!, and benign .declaring! 
are preserved by get .convictions with a fixed argument d. 


Conclusion 

We have provided a complete formal model of two of SPIDER’s protocols: Interactive Consistency and 
Diagnosis. We have given formal proofs in PVS that under the Dynamic Fault Assumption and the Correct 
Active Sources Assumption. Interactive Consistency satisfies Validity and Agreement, and that Diagnosis 
preserves the Dynamic Fault Assumption and the Correct Active Sources Assumption and moreover is able 

to declare some faulty nodes. T . 

The design effort and the parallel Formal Verification effort showed a remarkable* cross-fertilization. 

symmetric. -agreement'! property was first introduced as a fix to the formal verification. Later it turned out to 
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l)(> an essential premise. Considerations for readniission of transiently faulty nodes showed that. Step 2 in the 
Interactive Consistency Protocol effectively prevented a recovering node from ever being readmitted. The 
ensuing redesign uncovered the potential to straighten the PVS code of the Interactive Consistency Protocol. 
That in turn lead to the presentation of Interactive Consistency as a combination of single source broadcast 
and consistent source exchange, the latter being reused for declaration exchange. The discovery that the 
Maximum Fault Assumption was unsuitable for readmission led to a complete redesign that culminated in 
the failure of agreement of Interactive Consistency and the recognized need for Step 5. 

Probably the most important lesson that we can draw is the following: If our conjecture that all accusa- 
tions against like nodes may be turned into declarations turns out true, then the Diagnosis Protocol can be 
simplified. The accused value for trust, values against, like* nodes, and the exchange of accusations against like 
nodes can be scrapped. This saves N x A* + M x M register bits and half the bandwidth of the accusation 
exchange*. 


References 

1. Patrick Lincoln and John Rushby. Formal verification of an interactive consistency algorithm for the Draper 
FTP architecture under a hybrid fault model. In COMPASS ’ 94 (Proceedings of the Ninth Annual Conference on 
Computer Assurance ), pages 107 120, Gaithersburg, MD. June 1994. IEEE Washington Section. 

2. Paul S. Miner. Mah.var Malekpour. and Wilfredo Torres-Pomales. Conceptual design of a Reliable Optical BUS 
(ROBUS). In Digital Avionics Systems Conference DASC, October 2002. To Appear. 

3. Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault- tolerant 
architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering . 2 1(2): 107 125. 
February 1995. 

4. John Rushby. Systematic formal verification for fault-tolerant time-triggered algorithms. IEEE Transactions on 
Software Engineering, 25(5):651 660, September/October 1999. 

5. John Rushbv. A comparison of bus architectures for safety-critical embedded systems. Technical re- 
port, Computer Science Laboratory, SRI International, Menlo Park, CA, September 2001. Available' at 
http://www.csl.sri.com/~rushby/abstracts/buscompare. 

6. T. Basil Smith. Fault tolerant processor concepts and operations. In Fault Tolerant Computing Symposium 14 ♦ 
pages 158 -163. IEEE Computer Society. 1984. 

7. Philip Thambidurai and You-Keun Park. Interactive consistency with multiple failure modes. In 7th Reliable 
Distributed Systems Symposium . pages 1-8, October 1988. 

8. C. J. Walter. R. M. Kieckhafer, and A. M. Finn. MAFT: A multicomputer architecture for fault-tolerance in 
real-time control systems. In IEEE Real-Time Systems Symposium, December 1985. 

9. Chris ,J. Walter, Patrick Lincoln, and Neeraj Suri. Formally verified on-line diagnosis. IEEE Transactions on 
Software Engineering . 23( 1 1 ) :684 721, November 1997. 


Using HOL to Study Sugar 2.0 Semantics 


Michael .1. C. Gordon 

University of Cambridge Computer Laboratory 
William Gates Building, J.J Thomson Avenue, Cambridge CB3 OFD. U K. 

mjcgQc:l .cam.ac.uk 
http://www.cl . cam.ac.uk/~mjcg 


Abstract. The Arccllera standards- promoting organisation selected Sugar 2.0 , IBM s formal spc»< iti- 
cation language, as a standard that it says ‘will drive assertion-based verification". Sugar 2. combines 
aspects of Interval Temporal Logic (ITL), Linear Temporal Logic (LTL) and Computation Tree Logic 
(CTL) into a property language suitable for both formal verification and use with simulation test 
benches. As industrial strength languages go it is remarkably elegant, consisting of a small kernel 
conservatively extended bv numerous definitions or 'syntactic sugar (hence the name). 

We are constructing a semantic embedding of Sugar 2.0 in the version of higher order logic supported 
by the HOL system. To sanitv check’ the semantics we tried to prove some simple properties and as 
a result a few small bugs were discovered. We hope eventually to obtain a formal semantics that, with 
high confidence, matches the official ‘golden semantics issued by At cellera. 

We are contemplating a variety of applications of the semantics, including building a semantics-directed 
Sugar model checker inside HOL. We also hope to investigate generating checkers by executing proof 
scripts that rewrite the semantics of particular constructs into an executable form. In the longer term 
we want, to investigate the use of theorem proving to reason about models with infinite state spates, 
which might, involve developing extensions of Sugar 2.0. 


1 Background on Accellera and Sugar 

The Accellera organisation’s website has their mission statement: 

To improve designers' productivity, the electronic design industry needs a methodology based on 
both worldwide standards and open interfaces. Accellera was formed in 2000 through the unifica- 
tion of Open Verilog International and VHDL International to focus on identifying new standards, 
development of standards and formats, and to foster the adoption of new methodologies. 

Accellera ’s mission is to drive worldwide development and use of standards required by systems, semi- 
conductor and design tools companies, which enhance a language-based design automation process i. 

Its Board of Directors guides all the operations and activities of the organisation and is comprised 
of representatives from ASIC manufacturers, systems companies and design tool vendors. 

Faced with several syntactically and semantically incompatible formal property languages. Accellera initiated 
a process of selecting a standard property language to “drive assertion-based verification . 

Four contributions were initially considered 

- Motorola’s CBY language; 

- IBM's Sugar (the language of its RuleBase FY toolset); 

- Intel’s ForSpec; 

- Verisity’s e language (the language of the Specman Elite test-bench). 

After a combination of discussion and voting, some details of which can be viewed on the web 1 attention 
was narrowed down to Sugar and CBY, and then in April 2002 a vote 2 selected IBM's submission, Sugar 2.0. 
Sugar 2.0 is primarily an LTL-based language that is a successor to the CTL-based Sugar 1 [1]. A key idea 
of both languages is the use of ITL-like [4] constructs called Sugar Extended Regular Expressions. Sugar 2.0 


1 http:// www.eda. org/ v fv / hm / 

2 http:/ / www. eda.org/vfv/hin/0795.html 
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retains CTL constructs in its Optional Branching Extension (OBE), but this is do-emphasised in the defining 
document.. 

Besides moving from CTL to LTL, Sugar 2.0 supports clocking and finite paths. Clocking allows one to specify 
on which clock edges signals are sampled. The finite path semantics allows properties to be interpreted on 
simulation runs, as in test-bench tools like Vera and Speemair* 

The addition of clocking and finite path semantics makes the Sugar 2.0 semantics more than twice as 
complicated as the Sugar 1 semantics. However, for a real ‘industry standard’ language Sugar 2.0 is still 
remarkably simple, and it was routine to define the abstract syntax and semantics of the whole language in 
the logic of the HOL system [3]. 

In Section 2 we discuss the point of embedding Sugar in HOL. In Section 3, semantic embedding is reviewed 
and illustrated on simplified semantics of fragments of Sugar 2.0 . In Section 4. the semantics of full Sugar 2.0 
is discussed, including finite paths and clocking. Due to space limitations, the complete semantics of Sugar 2.0 
is not given here, but can be found on the web.' 1 In Section 5, progress so far in analysing the semantics 
using the HOL system is discussed. Finally, there is a short section of conclusions. 

2 Why embed Sugar in HOL? 

There are several justifications for the work described here. This project started in April 2002 and its goals 
are still being defined. Current motivations include the following. 

2.1 Sanity checking and proving meta-theorems 

By formalising the semantics and passing it through a parser and type-checker one achieves a first level 
of sanity checking of the definition. One also exposes possible ambiguities, fuzzy corner cases etc (e.g. see 
Section 4.2). The process is also very educational for the formaliser and a good learning exercise. 

There are a number of meta-theorems one might expect to be true, and proving them with a theorem 
prover provides a further and deeper kind of sanity checking. In the case of Sugar 2.0 , such meta-theorems 
include showing that expected simplifications to the semantics occur if there is no non-trivial clocking, that 
different semantics of docking are equivalent, and that if finite paths are ignored then the standard Text-book 
semantics 1 results. Such meta-theorems are generally mathematically shallow, but full of tedious details 
i.e. ideal for automated theorem proving. See Section 5 for what we have proved so far. 

2.2 Validating definitional extensions 

A key feature of the Sugar approach indeed the feature from which the name “Sugar' 1 is derived is to 
have a minimal kernel augmented with a large number of definitions i.e. syntactic sugar to enhance the 
usability (but. not the expressive power) of the language. 

The definitions can he validated by proving that they achieve the correct semantics. See the end of Section 5.3 
for some examples. 

2.3 Machine processable semantics 

The current Sugar 2.0 document is admirably clear, but it is informal mathematics presented as typeset 
text. Tool developers could bemefit from a machine readable version. One might think of using some standard 
representation of mathematical content, like MathMI. r> , however there is currently not much mathematically 
sophisticated tool support for such XML-based representations. See the end of Section 5.4 for a bit more 
discussion. 

Higher order logic is a widely used formalisation medium (versions of higher order logic are used by HOL, 
Isabelle/HOL, PVS, XuPrl and Coq) and the semantic embedding of model-checkable logics in HOL is 
standard [6,5]. Once one has a representation in higher order logic, then representations in other formats 
should be straightforward to derive. 

3 There is a ‘Suga^e’ tool available from NoBug Consulting. 

1 http:// www.d . ram .ac.uk/~mjcg/Sugar/ 

* ht t p : / / www . w3 . org / Mat h / 
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2.4 Basis for research 

We hope to develop semantically-based reasoning and checking infrastructure in HOL to support Sugar 2.0. 
and a prerequisite for this is to Wave a ‘golden semantics’ to winch application-specific semantics can >e 

proved equivalent. . . , , 

We are interested in the development of property languages that support data operations and Lvana Rang- 
ing over infinite data-tvpes like numbers (e.g. including reals and complex numbers for DSP apphcations). 
Some sort, of mixture of Hoare Logic and Sugar 2.0 is being contemplated. Increment alh ‘ ' 

structs by extending an existing semantics of Sugar 2.0 is a way to ensure some backward compatibility « th 
industry-standard language. Also, we might wish to prove sanity checking meta-theorem about our ext( ndc 
language e.g. that it collapses to Sugar 2.0 when there are no infinite types. 

Sugar 2.0 is explicitly designed for use with simulation as well as formal verification. \\e are interested 
in using the HOL platform to experiment with combinations of execution, checking and theorem-proung. 
To this R end we are thinking about implementing tools to transform properties stated m Sugar to checking 
automata. This is inspired by IBM's FoCs project 6 , but uses compilation by theorem proving to ensure 
semantic equivalence between the executable checker and the sourte piopeitw 


2.5 Education 

Both semantic embedding and property specification are taught as part of the Computer Science unchjgrad- 
uat e course at Cambridge University, and being able to illustrate the ideas on a real example like Sugar , 0 
is pedagogic-ally valuable. Teaching an industrial property language nicely complements and motivates aca- 
demic languages like ITL, LI L and CTL. 

The semantic embedding of Sugar 2.0 in the HOL system is an interesting case study. It titrates some 
issues hi making total functional definitions, and the formal challenges attempted so far provide insight into 
how to perform structural induction using the built-in tools. Thus Sugar 2.0 has educational Potted, ( » 
training HOL users. In fact, the semantics described in this paper is an example distributed with HOL. 


3 Review of semantic embedding in higher order logic 

Higher order logic is an extension of first-order predicate calculus that allows quantification over functions 
and relations. It is a natural notation for formalising informal set theoretic specifications (indeed, it is usua y 
more natural than formal first-order set theories, like ZF). We hope that the HOL notation we use in what 
follows is sufficiently close' to standard informal mathematics that it needs no systematic explanation. 

We use Church's A-notation for denoting functions: a ‘lambda-term' like Ax. t, where x is a variable and 
t a term, denotes the function that maps a value v to the result of substituting v for the variable x m 
(the infix notation x hi < is sometimes used instead of Ax. t). If P is a function that returns a truth-value 
(i.e. a predicate), then P can be thought of a set, and we write x £ P to mean P(x) is true Note 
Ax. • • • x • ■ • corresponds to the set abstraction {x | •■•*•••}• We write Vx £ P. Q(x). 3x £ ■ J{x) to mean 

Vx. P(x) =► Q{x). 3x. P(x) A Q(x), respectively. 

To embed 6 a language in HOL one first defines constructors for all the syntactic constructs of the language 
This is the ‘abstract syntax’ and provides a representation of parse- trees as terms in the logic. The- semantics 
is then specified by defining a semantic function that recursively maps each construct to a representation o 

its meaning. . , , r 

For Sugar 2.0. a model M is a quintuple (S M . S oM , R*p Pm- l m)> «'here S M is a set o states S 0 m 1S * “ 

initial states. E„ is a transition relation (so R m (m') means .s' is a possible successor state to -a), Pj| [ * • « 
of atomic propositions, and L„ is a valuation that maps a state to the set of atomic propositions that hold 
at the state (so L M ,s p is true if!' atomic proposition p is true m state s). 

6 http: / / www.haifa.il.ibrn. coni /projects/ verification/focs/ 

7 http: / /cvs. sourcc-forge. net/egi-bin/ viewcvs.cgi/hol/hol98/examplcs/Sugar2/ 

6 We shall only be concerned with so c alled ‘deep embeddings' here [2). 
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3.1 Boolean expressions in Sugar 

The syntax of boolean expressions (ranged over by b. b,, b, etc.) is built, from atomic propositions (ranged 
over by p) using negation (-.) and conjunction (A): 

b p (Atomic formula) 

| ->b (Negation) 

| b i A b*> (Conjunction) 

Tins is defined m HOL by a recursive type definition of a type that, represents the syntax of boolean 
expressions. Other boolean expressions are added via definitions (e.g. see Section 5.3 for the definition of 
disjunction: bj V b L >). 

Let 1 range over predicates on P M , called “truth assignments” in the Sugar documentation. The semantics 
of boolean expressions is given by defining a semantic function BJ3EM such that B_SEM M 1 b if true iff b is 
built from propositions in and it is true with respect to the truth assignment 1. 

If we write (M. 1 f= b ) for ELSEM M 1 b then the semantics i s given by 

( (M, 1 |= p) = p 6 P M A p 6 1) 

A 

((M. 1 )= T) = T) 

A 

( (M, 1 |= -ib) = — > (M, 1 |= b)) 

A 

((M, 1 (= blAb2) = (M. 1 |= bl) A (M, 1 j= b2) ) 

Note that the symbol A is overloaded: the first occurrence in the equation above is part of the boolean 
expression syntax of Sugar, but the second occurrence is higher order logic. 

Before looking at the full semantics of Sugar 2.0. we first consider a simplified semantics in which there is 
no clocking, and paths are always infinite. We consider separately the parts of Sugar 2.0 corresponding to 
Interval Temporal Logic (ITL), Linear Temporal Logic (LTL) and Computation Tree Logic (CTL). 


3.2 ITL: Sugar Extended Regular Expressions (SEREs) 


Interval Temporal Logic (ITL) provides formulas that are true or false of intervals of states. Here we just 
consider finite intervals, though recent formulations of ITL 9 allow intervals to be infinite. For Sugar we only 
need to consider ITL formulas, as there are no constructs corresponding to ITL expressions (expressions map 

intervals to values). Providing more elaborate ITL constructs in Sugar strikes us as an interesting research 
topic. 

The Sugar subset corresponding to ITL is called Sugar Extended Regular Expressions (SEREs). If r, iq. r > 
etc. range over SEREs and p ranges over the set P M of atomic propositions, then the syntax is given by: 


I i r i} I { r 2 } 

I r, ; r 2 
I r i : r 2 
| {rq } && {r-? } 
I { r i} & {r 2} 


(Atomic formula) 

(Disjunction) 

(Concatenation) 

(Fusion: ITL’s chop) 

(Length matching conjunction) 
(Flexible matching conjunction) 
(Repeat) 


The semantics of SEREs is given by defining a semantic function S_SEM such that S_SEM M w r if true iff w is 
in the language of the extended regular expression r. We write (M, w |= r) for S _SEM M w r. 

If wlist is a list of lists then Concat wlist is the concatenation of the lists in wlist and if P is some 
predicate then Every P wlist means that P( w) holds for every w in wlist. 

The semantics S_SEM M w r is defined in HOL by recursion on r. 

9 http://www.cms.dniu.ac.uk/~cau/itlhomepage/ 
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((M. w (= b) = 

31. (w = [1]) A (M, 1 (= b)) 

A 

((M, w |= rl;r2) = 

3wl w2 . (w = wlw2) A (M. wl |= rl) A (M, w2 |= r2)) 

A 

((M. w )= rl:r2) = 

3wl w2 1. (w = wl [1] w2) A 

(M. (wl Cl] ) N rl) A (M. ( [1] w2) 1= r2)) 

A 

((M. w |= {rl} I{r2}) = 

(M. w |= rl) V (M. w ]= r2) ) 

A 

((M. w |= {rl}&&{r2}) = 

(M. w (= rl) A (M, w |== r2) ) 

A 

((M, w }= {rl}&{r2}) = 

3wl w2 . (w = wlw2) A 

( C (M. w 1= rl) A (M. wl {= r2) ) 

V 

( (M, w |= r2) A (M. wl |= rl)))) 

A 

((M, w }= r[*]) = 

3wlist. (w = Concat wlist) A Every (Aw. (M. w j= r)) wlist) 

This definition is manifestly primitive- recursive, and so is automatically proved total by HOL [<]• The 
intuitive semantics of SERE's is explained in the Sugar 2.0 documentation [8]. 


3.3 LTL: Sugar Foundation Language (FL) 


Sugar 2.0 has a kernel combining standard LTL notation with a less standard abort operation and some 
constructs using SEREs. The suffix “!” found on some constructs indicates that these are strong (i.e. 
liveness-enforcing) operators. The distinction between strong and weak operators is discussed and motivated 
in the Sugar 2.0 literature (e.g. [9, Section 4.11]). 


I -f 

| fi A f-, 

| X ! f 

| [fi Uf 2 ] 

I W(f) 

I {ri } |-> {r > } ! 
j {ri } |-> {r 2 } 

| f abort b 


(Atomic formula) 
(Negation) 

(Conjunction) 

(Successor) 

(Until) 

(Suffix implication) 
(Strong suffix implication) 
(Weak suffix implication) 
(Abort) 


Numerous additional notations are introduced as syntactic sugar. These are easily formalised as definitions 
in HOL. Some examples are given in Section 5.3. 

Being LTL, the semantics of FL formulas is defined with respect to a path tt. which (in the simplified 
semantics here) is a function from the natural numbers to states. 

We define a semantic function F.SEM such that F_SEM M tt f means FL formula f is true of path jt. We write 
(M. tt \= r) for F_SEM M tt f. 

Note that in the semantics below it is not assumed that paths tt are necessarily computations of M (i.e. satisfy 
Path M tt. as defined in Section 3.4). This is important for the abort construct (where the 3 tt quantities 

over all paths). 
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The notation tr, denotes the »-th state in the path (i.e. -(/)); tt' denotes the •/- th tail' of tt the path obtained 
by chopping * elements off the front of 7 r (i.e. tt* = An. *(«+»)); 7r<0> denotes the finite sequent* of states 
from i to j in i.e. 7r,7t, :+1 The juxtaposition denotes the path obtained by concatenating the 

finite sequence on to the front of the path tt' . 

The function L M denotes the point-wise extension of L M to finite sequences of states (i.e. MAP L M in HOL and 
functional programming notation). 

EM M tt f is by recursion on f . 


The definition of 

( CM. 7 r 

t= 

A 

((M, 7T 
A 

(= 

((M, tt 
A 

h 

( (M, 7 r 

N 

A 


( (M. TT 

h 


MM, 


h f)) 


3k. (M. 7r k |= f 2) A Vj . j < k => (M, |= f 1) ) 

A 

((M, tt |= {r }(f )) = 

Vj. (M, (Ln (7 t {0 'V)) f= r) => (M, tt* |= f)) 

A 

((M, tt |= { r 1 } | “ > { r 2 } ? ) = 

Vj. (M. (Ln (7r ( °d>)) [= rl) 

=> 3k. j < k A CM, (L n (7T<^* k >)) (= r2) ) 

A 

((M, 7T (= {rl} | ->{r2}) = 

Vj. (M, (Ln (7T<°d))) (= rl) 

=> (3k. j < k A (M, (L„ (7T {j ' k) )) h r2) ) 

V 

Vk. j < k => 3w. (M, (Ln (7T ( j- k) ))w |= r2) ) 

A 

((M, 7r |= f abort b) = 

((M, TT (= f ) 

V 

3j 7T * . (M, tO \= b) A (M, 7T<°^- 1 > tt' |= f))) 


In this semantics, paths tt are infinite, as in the classical semantics of LTL for model checking. A version 
that also handles finite paths, suitable for evaluation on simulation runs, is given in Section 4.2. 


3.4 CTL: Sugar Optional Branching Extension (OBE) 

The syntax of the Sugar 2.0 OBE is completely standard. The syntax of the OBE formulas is 


f 


•= P 

I 

I ft A f 2 

| EXf 
| E[f j U 
| EGf 


(Atom) 

(Negation) 

(Conjunction) 

(Some successors) 

(Until - along some path) 
(Always on some path) 


For the semantics, define Path M tt to be true iff tt is a computation of M: 
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Path M 7 T = Vn. Ra/(~«» 

The semantic function O.SEM is defined so that D_SEM M s f is true iff f is true of M at state s. Write 
(M. s 1= f ) for 0_SEM M s f, which is defined by recursion on f by: 

((M. s |= b) = (M, Lh(s) 1 = b)) 

A 

(CM, s |= -rf) = -(M. s f)) 

A 

((M. s (= f 1 A f 2) = (M. s |= fl) A (M. s |= f2)) 

A 

(CM. s \= EX f) = 

3jt. Path M 7T A (7T 0 = s) A (M. TTi )= f)) 

A 

(CM, s 1= [fl U f 2] ) = 

3tt. Path M 7r A (tto = s) A 

(M, 7r k |= f2) A Vj. j < k => (M, 7Tj |= fl)) 

A 

( (M, s |= EG f) = 

3tt . Path M 7T A ( 7 Tq = s) A Vj . (M, 7tj f)) 


4 Full Sugar 2.0 semantics in higher order logic 

The full Sugar 2.0 language extends the constructs described above with the addition of clocking and support 

for finite paths. , 

The clocking constructs allow (possibly multiple) clocks to be declared, see Section 4.1. Clocks define when 
signals are sampled, so the next value of a signal s with respect to a clock c is the vain.' of s at the next 

rising edge of !c. . 

Simulators compute finite executions of a model, so to support checking whether a property holds over such 
a simulation run. Sugar 2.0 defines the meaning of each construct on both finite and infinite paths. 

Adding clocks and finite paths greatly complicates the language, though it. is still surprisingly elegant. 

We have formalised the full semantics of Sugar 2.0 via a deep embedding in higher order logic. Correspond- 
ing to Appendix A.l of the Sugar 2.0 specification submitted to Accellera [9] we have defined types bexp. 
sere, f 1 and obe in the HOL logic to represent, the syntax of Boolean Expressions, Sugar Extended Reg- 
ular Expressions (SEREs), formulas of the Sugar Foundation Language (FL) and formulas of the Optiona 
Branching Extension (OBE), respectively. 

Corresponding to Appendix A.2 of the Sugar documentation we have defined semantic functions B_SEM. S-SEM. 
F SEM and 0_SEM that interpret boolean expressions, SEREs, FL formulas and OBE formulas, respectively. 
Due to space constraints we do not give the semantics here, but full details are available on the web at: 

http:/ / www. cl. cam.ac.uk/ mjcg/Sugar 

The semantics is evolving and we hope to keep the HOL version up to date with respect, to the official version. 
In the next two sub-sections we discuss clocking and finite paths. 


4.1 Clocking 

If b is a boolean expression, then the SERE b@c recognises a sequence of states in which b is true on the 
next rising edge of c. Thus bQc behaves like {- , c[*] ; c A b}. 

More generally, if r is a SERE and c a variable then r®c is a SERE in which all variables inside r are clocked 
with respect to the rising edges of c. 

The semantics of clocked SEREs can be given in two ways: 
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1. by making a clocking context part of the semantic function, i.e. defining (M, w r) instead of the 
undocked (M, w (= r): 

2. by translating clocked SEREs into undocked SEREs using rewriting rules. 

\\ it h the first approacli (1). which is taken as the definition in the Accellera report, one defines 
(M. w f= b) = 

3n. n > 1 /\ 

(length w = n) A 

(Vi. l<iAi<n=> (M, w±-i -ic) A 
(M, w n _! |= c A b) 

(M, w |= r<9cl) = (M, w ^ r) 

together with equations like those in Section 3.2, but with £ replacing |=. Notice that an inner clock overrides 
an outer clock (i.e. cl is used to clock variables inside r in r@cl: the clock context c is overridden by cl 
inside r). 

The second approach (2) is to translate clocked SEREs to undocked SEREs using rewrites 

b@c — y {-ic[*]; cAb} 

{rl;r2}©c — > {rlOc} ; {r2Qc} 

{rl:r2}©c — > {rl©c} : {r2<3c} 

{ {r 1 } | {r2} }@c — > {r 10c} | {r2(Dc} 

{{rl}&&{r2}}0c — > {rl@c}&&{r2@c} 

{ {rl }&{r2 } }©c — > {rl©c)&{r2@c} 

r[*]@c — > {rQc} [*] 

rQclQc — > rlOcl 

these rewrites cannot be taken as equational definitions, but need to be applied from the outside in: e.g. one 
must rewrite b@cl®c to bQcl (eliminating c) rather than rewriting the sub-term b@cl first, resulting in 
{^cl [*] ; clAb}@c. We have proved the two semantics for clocking SEREs are equivalent, see Section 5.3. 
One can also clock formulas, f ©c, and there may be several docks. Consider: 10 

G(req_in -> X ! (req_out@cb) ) @ca 

this means that the entire formula is clocked on clock ca, except that signal req_out is clocked on cb. Clocks 
do not 'accumulate’, so the signal req.out is only clocked by cb, not by both docks. Thus cb ‘protects’ 
req^out from the main clock, ca, i.e.: 

req_out@cb®ca = req_out@cb 

As with the clocking of SEREs, this meaning of clocking prevents us simply defining: 
req_out<3cb = [~icb U (cb A req_out)] 
since if this were the definition of req_out@cb then we would he forced to have: 
req_out@cb®ca = [-.cb U (cb A req_out) ] Qca 
when we actually want 
req_out®cb®ca = req_out©cb 

Thus, as with SEREs, we cannot just rewrite away docking constructs using equational reasoning, but if 
one starts at the outside and works inwards, then one can systematically compile away clocking. The rules 
foi doing this are given in the Sugar 2.0 Accellera documentation as part of the implementation of formal 
verification [9, Appendix B.l], We are currently in the process of trying to validate the clocking rewrites, see 
Section 5.3. 

The discussion of docking here is based on email communication with Cindy Eisner. 
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^ i i:w, (^ \ a |, nv p of havinu. the currentlv active clock as an argument 

- - — — 

‘strong docking. The weak docking is specified in HOL by defining 
(M. 7T f) 

and the strong clocking by defining 
c ! 

no, gi'vo ,l,o eomplete so .ntte hero (they are available on the weh). jus, +m the -man, ins 

of boolean expressions b: 

( (M, 7r (= b) = 

Vi e plTT. (M, (£„ (7t ,0 - i! )) (= ->c[*] ; c) => (M. LhM 1= 

This says that if there is a first rising edge of c at time i, then b is true at i. 

( (M, 7T |=’ b) = 

BiGpltr. (M, (U ( tt * 0 - 1 *)) £ -c M;c) A (H, Ln(^) t= b)) 

This s-ivs that there, is a first rising edge, and if it occurs at time i. then b is true at i 

Thus the strongly clocked semantics assumes the clock is dive', but the weakly docke semantics 

(compare the concepts of total and partial correctness). 


4.2 Finite paths 

x* ?«£ «***» ^ ** *. - * «*• »■* <» - 

not defined on paths for which finite is not true). 

We interpret the official semantics locution 
“for every j < length(Tr): • ■ * j 

as meaning . 

“for every j: (finite tt implies j < length 7r) implies ■ * * j 

and we interpret the official semantics locution 
“there exists j < length(7r) s.t. j 

as meaning . „ 

“there exists j s.t. (finite tt implies j < length tt) and J 
Define pi tr » to mean ,h„, if a is finite -hen n is less than the lenfi.h of ». U. the P"*™' P» 18 **** * 

plan = finite * * „< length » tor the 1„™, ions .hove. The “pi" 

We can then write Vf £ pi a. • • • i • • • and fc pi ir- 
is short for “path length 

Here is a version of the undocked FL semantics that allows paths to be finite. 

((M, tt |= b) = (M. Lm(tto) 1= h)) 

A 

((M, 7 r \= "’f) = ^ N 

((M, 7T |= f 1 A f 2) = (M, tt (= fl) A (M. 7T |= f2)) 

((M tt 1= X! f) = pl tt 1 A (M, 7T 1 1= f)) 

11 Thett ctdfor finite paths to be non-empty ««. when trying to prove son.e properties. This rent, ire, non, does no, 
seem to be explicit in the Accellera specification. 
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((M, 7r \= [fl U f2]) = 

3k 6 pi 7r . 

(M. ~ k j= f2) A Vj € pi 7T . j < k => (M, ttJ |= fl)) 

A 

((M. 7T (= {r}(f )) = 

Vj £ pl<r. (M, (£ M (7 t , 0 3>)) (= r) =t> (M, ni (= f)) 

A 

( CM- 7T (= {rl } | ->{r2} ! ) = 

Vj € pljr. (M, (£« (?r' 0 'j))) j= rl) 

=> 3k £ pin-, j < k A (M. (£„ (TrO-kl)) (= r2 )) 

A 

((M, jt (= {rl } | ->{r2}) = 

Vj eplTr. CM, (£„ (jr<°J>)) (= rl) 

=> (3k € pi tt. j < k A (M. (£„ (7rO-k))) (= r2 )) 

V 

Vk £ pi 7r . j < k => 3w. (M, (£„ ( 7 T (j - k) ))w {= r2) ) 

A 

((M, 7r (= f abort b) = 

(CM, 7T {= f ) 

V 

3j £ pi 7T . 

0 < j A 3tr*. (M. 7rJ |= b) A (M, 7 r«>d-i) {= f))) 

This semantics has evolved from an existing unpublished semantics 12 of unclocked FL formulas. 


5 Progress on analysing the semantics 


\\e have established a number of properties of the semantics using the HOL system. Some of these went 
through hrst time without any problems, but others revealed bugs both in the Sugar 2.0 semantics and 
original HOL representation of the semantics. 


5.1 Characterising adjacent rising edges 

Define: 


FirstRise H ir c i = (M. (£„ (7r (0 i >)) £ -.c[*];c) 
NextRise M jr c (i.j) = (M, (£„ (ttOO))) (I -, c [*];c) 


The right hand sides of these definition occur in the Sugar 2.0 semantics. We have proved that the definitions 
° Flr stRise and NextRise give them the correct meaning, namely FirstRise M tt c i is true iff i is the 
ofTaher i ° f C ’ 811(1 NextRise M * c (i > j) is true iff j is the time of the first rising edge 


h FirstRise M tt c i = 

(Vj. j < i =► — >(M, LmCttj) |= c)) A (M. L„( 7 ri) (= c) 


h i < j 

(NextRise M ?r c (i, j) = 

( Vk - 1 ^ k A k < j => -i(M, L M (7r k ) |= c)) A (M, L M (ffj) (= c)) 
12 Personal communication from Cindy Eisner. 
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The- proof of these were essentially routine, though quite a bit more tricky than expected. Immediate enrol- 
laries are 

h FirstRise M 7r T i = (i = 0) 
b i < j => (NextRise M 7T T (i,j) = U = j)) 

5.2 Relating the clocked and unclocked semantics 

If we define ClockFree r to mean that r contains no clocking constructs (a simple recursion over the syntax 
of SEREs). tht'n clocking with T is equivalent to the unclocked SERE semantics. 

T 

h Vr. ClockFree r =4- ((M. w (= r) = ( M - w N r )) 

The proof of this is an easy structural induction, and shows that when the clock is T. the . locked semantics 
of SEREs collapses to the semantics in Section 3.2. 

We tried to prove a similar result for FL formulas, hut at first this turned out to be impossible. The reason 
was that the proof required first showing 

Vf (M, 7t |2 f) = (M, 7T |2' f)) 

However, the original semantics had the following: 

(M. 7 r [= ! b) = 3i. FirstRise M 7t c i A (M, L M (7Ti) 1= b) 

(M, 7 r (= b) = 3i . FirstRise M tt c i => (M, Ln(7ti) |= b) 

Instantiating c to T and using the corollary about FirstRise yields 

(M, tt | 2 ! b) = 3i . (i=0) A (M. L M (~ i) |= b) 

(M, tt [= b) = 3i. (i=0) => (M. L M (tti ) b) 

With this, clearly (M. tt, £ b) is not equal to (M, Tt £' ' b). The solution, suggested by Cindy Eisner, is to 
replace the weak semantics by 

(M. 7 T £ b) = Vi. FirstRise M n c i => (M, LmC^) b) 
so that we get 

(M, -r | 2 ! b) = 3i. (i=0) A (M, L„(7ti) \= b) 

(M. 7t (2 b) = Vi. (i=0) => (M. Ln(tti) |= b) 

which makes (M. tt (2 b) equal to (M, tt £' b). The same change of 3 to Vis also needed for the semantics of 
weak clocking for f 1 A f2, X! f, {r}(f), {rl}|->-{r2} and f abort b. With these changes, we used structura 

induction to prove: 13 

h Vf 7 r. (M, TT (2 f) = (M. 77 |2- f) 

However, we were still unable to prove 
b Vf. ClockFree f => ( (M . tt |= f) = (M, 7t |= f)) 

where here ClockFree f means that f contains no clocked FL formulas or SEREs. The proof attempt failed 
because the undocked semantics for [f 1 U f2] had a path length check, but the strongly clocked seman us 
didn’t . After restricting the quantification of a variable in the strongly docked semantics to values satisfying 

pl tt. the proof went through. 

13 See Section 5.4 for further developments! 
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5.3 Validating the clock implementation rewriting rules 

As discussed in Section 4.1, the semantics of clocked SEREs and formulas can be given in two ways: 

c c ' 

1. by defining (= and, for formulas, (=* ; 

2. by translating away clocking constructs r«c, f«c and f®c! using rewrites, then using the undocked 
semantics f=. 

The representation in HOL of the direct semantics (1) has already been discussed. 

The definition of the translation (2) in HOL is straightforward: one just defines recursive functions SClocklmp, 
that takes a dock and a SERE and returns a SERE, and FClocklmp that takes a dock context and a formula 
and returns a formula. Thus roughly 14 

SClocklmp : clock — > sere — ► sere 
FClocklmp : clock — * fl — » fl 

Wo can then attempt to prove that 

b Vr w c. (M, w (= r) = (M, w \= SClockComp c r) 

which turns out to be a routine proof by structural induction on r. However, the results for formulas 

b Vf 7r c. (M. 7r |= f) = (M. 7T |= FClockComp c f) 
c ! 

b Vf 7T c. (M, 7r f= f) = (M„ 7T |= FClockComp c! f) 

are harder, and we have not yet finished proving these (as of 5 July 2002). To see the complexity involved 
consider the rewrite for weakly docked conjunctions [9, page 67]: 

(fl A f2)Qc — > [~»c W (c A (fl@c A f2<3c))] 

wht're W is the ‘weak until’ operator which is part of the definitional extension (i.e. syntactic sugar) defined 

as part of Sugar 2.0 , namely: 

[fl W f 2] = [fl U f2] V G fl 

where U is a primitive (part of the kernel) hut V and G are defined by: 

fl V f2 = ->(— if 1 A -if 2) 

G f = — »F ( — if) 

and F is defined by 

F f = [T U f] 

Let us define 

FClockCorrect M f = (Vtt c. (M, tt £ f ) = (M, tt |= FClockComp c f )) 

A 

c * 

(Vtt c. (M. 7r f=' f ) = (M, ~ |= FClockComp c! f)) 

It, is relatively straightforward to prove the cases for boolean formulas b and negations -if, namely: 
b VM. FClockCorrect M b 

b VM f . FClockCorrect Mf => FClockCorrect M (-if) 

For formula conjunction we want to prove: 

VM fl f2. FClockCorrect M fl A FClockCorrect M f2 => FClockCorrect M (fl A f 2) 

where the firs t A is in higher order logic and the one in f 1 A f2 is part of the Sugar formula syntax. 

We are glossing over details here, like what the type clock exactly is. 


14 
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Wo got hogged down in details when we tried to prove this directly, so we hist established some lemmas 
about V and the undocked semant ics of the defined operators W. G and F. 

(M, 7 T t= f 1 V f 2) = (M, JT 1= fl) v (M, 7T 1= f2) 

h (M. 7r |= F f) = 3iGplJT. (M. 7 ?^ |= f) 

b (M. 7T t= G f) = Vi G pi tt. (M. tt 1 |= f) 

h -.(M, TT 1= G f) = 3i G pltt. (M, 7 r 1 |= -*) 

(- — >(M, 7T [= G f) = 3iGpl7T. (M. TT 1 1= -f) A VjGplTT. j<i => (M, ^ 1= f) 

b (M, 7 r |= [fl w f 2] ) = (M. 7T t= [fl u f 2] ) V (M, 7T 1= G fl) 

Using these lemmas it is not too hard to prove the desired result about conjunctions. Besides helping with 
the proof of this, the lemmas also provide some sanity checking of the definitions. 


5.4 Restricting quantifiers 

The original semantics specifies that some of the quantifications over integer variables be restricted to range 
over values the are smaller than the length of the current path tt (we represent this using pi n) Our initial 
attempts to relate the clocked and undocked semantics needed additional quantifier restrictions to be added, 
as discussed at the end of Section 5.2 above. However, during email discussions with the Sugai 2.0 designers 
it became clear that in fact all quantifications should be restricted, for otherwise the semantics wouldwfe 
on the HOL logic’s default interpretations of terms like 7r J when n is finite and j _ g »■ 

HOL’s default interpretation of ‘meaningless' terms, it is unclear whether the semantics accma c > r< c< s 

the designers intentions. . 

Thus the semantics was modified so that all quantifications are suitably restricted. In addition, and m the 
same Spirit, we added the requirement that all terms *<-> occurred in a context where j. so hat the 
arbitrary value of when i > j was never invoked. Unfortunately these changes broke the proof of. 


b Vf 7T. (M, 


T ,T! 

f= f) = (M, tr \= 


and hence the proof relating the clocked and undocked semantics. However it ^^’Xen^l >^d 
bug in the semantics: “1 > k" occurred in a couple of places where there should hate been 1 > k an 
when this change was made t he proof of the above property, and the equivalence between the undocked and 

true-clocked semantics, went through. . .. 

However, just as we thought everything was sorted out, the Sugar 2.0 designers announced they had dis- 
covered a bug and pointed out that without their fix we should not have been able to prove what w< had. 
This bug had arisen in the semantics of X! formulas when the 3-to-V change to the weakly docked semantic s 
(which we discussed in Section 5.2) was made. 

Careful manual analysis showed that, an error in the HOL semantics had b^n introduced vTen t^ 
change was made, and this error masked the bug that should have appeared when we tried to do the proof. 
Thus a bug in the HOL semantics allowed a proof to succeed when it shouldn't have! After removing the 
transcription error from the HOL semantics the proofs failed, as they should, and after the eorree . . 
supplied bv the Sugar designers, was made to the semantics the proofs went through. 

This experience with a transcription error masking a bug has sensitised us to the dangers * re- 
translating the typeset semantics into HOL. We had carefully and systematically manualb chi kul that 
the HOL was a correct more than once, but nevertheless the error escaped detection. As a result, we a re 
experimenting with wavs of structuring ET E X source to represent the ‘deep structure of the semantics rather 
than its surface form’. The idea is to define OT E Xcommands (macros) that are semantically nieanu|g d an 
can be parsed directly into logic with a simple script. The definitions of the commands will then 

is The logical treatment of ‘undefined’ terms like 1/0 or hd[] has been much discussed. HOL uses a simple and 
consistent approach based on Hilbert’s -operator. Other approaches include ‘free logics (i.c. logics with not - 
denoting terms) and three- valued logics in which formulas can evaluate to true, false and undefined. 
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goneiate t he publication form of the semantics. By giving the commands extra parameters that can be used 
to hold strings foi generating English, but ignored when translating to HOL, it appears possible to ttse L'TgX 
to represent the semantics. However, the resulting document, source is rather complex and may be hard to 
maintain. The lotrg term ‘industry standard solution to this problem is to use XML (e.g. MathML), but 
current infrastructure for MathML is either trot quite ready (e.g. Publicon 18 ) or not quite polished enough 
for everyday use (e.g. IBM t exexplorer 17 , Mozilla 1 * and TtM 19 ) 


6 Conclusions 

It was quite straightforward to use the informal semantics in the Sugar 2.0 documentation to create a deep 
embedding of the whole Sugar 2.0 kernel. Attempting to prove some simple ‘sanity checking' lemmas with 
a proof assistant quickly revealed bugs in the translated semantics (and possibly in the original). Further 
probing revealed more bugs. 

It is hoped that the semantics in HOL that we now have is correct, but until further properties an* proved 
we cannot, be sure, and the experience so far suggests caution! 
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Abstract. With the continuing growth of computer systems including safety critical computer control 
systems the need for reliable tools to help construct, analyze, and verify such systems also continues 
to grow. An example of such a tool is DOVE [1, 2], One of the advantages of DO\ E is that it combines 
the ease of use provide bv a graphical user interface for describing specifications in the form of finite 
state machines with the rigor of proving linear temporal logic properties in a . robust theorem prover- 
Isabelle [5]. In the work described in this paper we increase the utility of DOVE by extending it vu 
the capability to build systems by specifying c omponents. 


1 Introduction 

The need for effective assurance in the design of critical systems continues to grow as our dependence on 
such systems continues to spread and grow. In many cases, death or injury can be easily caused by any 
faults in these critical systems, such as safety critical systems. To try to address this need, there is a growing 
variety of formal methods tools. Those tools are based on a variety of differing underlying methods. To be 
used outside the research community, such a tool must he fairly easy to use. and usua y wem c require a 
graphical user interface. The aim of the Design Oriented Verification and Evaluation (DOVE) [1,2], which 
was designed by the Defense' Science and Technology Organization (DSTO) in Australia, is to provide a 

powerful tool to meet this challenge. „ . , . 

DOVE comprises three main components: the graphical editor for drawing finite state mac mu as sp 
ifications of systems, the animator for exploring various execution paths, and a prover built on Isabelle 
[51 for verifying temporal logic properties of state machine. DOVE combines the ease of use afforded bv 
a graphical user interface, and the rigor afforded by formalizing and proving properties of a system m a 
theorem prover. The ability to model a system using the graphical editor substantially speeds the process 
and increases the confidence- level, when compared to describing the system as expressions in a language. 
The ability to visualize the graph is an early aid to catching simple hut important mistakes. The ability o 
explore sample executions through animation helps the user to deepen his understanding of state machine 
and to do a limited degree of test ing. The highest, degree of assurance is provided by stating and proving the 
needed properties of the system using the prover. 

There are limitations to t he use of a graphical editor once the system begins to get large. It is difficult to 
comprehend, let alone draw, a system that has in excess of one hundred nodes. Programming languages have 
used modules as a technique for controlling the complexity of systems. The purpose of the work discussed in 
this paper is to extend DOVE with the ability to build systems by composing them from simpler component 

machines. 


2 Overview of DOVE 

DOVE is primarily a tool for producing high assurance system designs. It provides tools for constructing, 
presenting and reasoning about formal design-models. DOVE is built in layers with a graphical user interface 
that is used for constructing and examining the design- models, and an underlying layer using t it- . ieort.ni 
prover Isabelle. The graphical interface of DOVE is written using Tcl/Tk script language. Isabelle is built 
in the functional programming language ML, and the proof is carried out by Isabelle. 

* This work was supported by ARC) Contract Number: DAAD-19-01-1-0473. 
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DOVE list's a state-machine mechanism to model the specification of system behavior. A state machine 
in DO\ E introduces the notion of a memory at each state, which is updated by each consecutive transition 
which describes how to evolve between states. The state machine graph consisted of nodes and edges which 
represent states and transitions. There must be at least one node in the state machine and exactly one node 
to be defined as the initial state. Each transition has three parts: Let, Guard and Act. The Let part is used 
to simplify the other two parts of the transition definition. The transition is only performed if the guard 
is satisfied m the correct memory. The Act. referring to action, defines how the memory is changed In- the 
transition (which only (‘an occur when the transition is performed). 

In addition to the visual inspection that the graphical interfaces allows. DOVE provides two other mech- 
anisms for analyzing system designs, namely animations and verification. Animation in DOVE begins In- 
setting initial values for the heap variables (i.e. setting the initial memory), and then is carried out by click- 
ing edges of the state machine graph and calculating new values for the heap variables in accordance with 
the the corresponding transition definition. This symbolic feature provides a useful way to check whether all 
variables are updated as expected and whether the transition, which is protected by the guard definition, is 
performed correct ly. However, the animation only gives a simple assurance of correctness of the design of the 

state machine. A higher level of assurance can be gained by proving whether the design satisfies the given 
requirements. 

Verification in DOVE provides powerful facilities to express properties and to prove the system satisfies 
system requirements. The system requirements must be translated from informal English into a particular 
version of linear temporal logic supported by DOVE. DOVE then provides a collection of proof rules and 
tactics specialized for proving these linear temporal logic properties. 

We have applied the DOVE tool to some medium-sized critical systems. The precise details of those 
applications are not relevant to this paper and are not included here. However, we will include a brief 
example motivated by our application as an illustration of some of the features of DOVE, and the limitation 
we wish to address here. The example system is intended to monitor the behavior of another device. The 
example system consists of two components: a component for monitoring whether the device is plugged 
in and receiving adequate power, and a component for monitoring when the device is adequately powered 
whether it is producing values within an acceptable range. 

Figure 1 shows a screen snapshot of the DOVE canvas for the Plugin Monitor component of the system. 
The giidded canvas is the DOVE state machine window which is used for designing the machine. The three 
nodes representing the three states in the Plugin Monitor model are Wait, CheckPlugin and CheckUnplug 
The edges with appropriate labels are transitions between these states. Several variables are needed. The 
heap variable Pluggedln represents whether the machine is plugged in. the input variable Volt is supplied by 
the environment and is monitored to trace when the device is properly plugged in. Finally, an initial state 
Wait should be defined in which the machine is unplugged. 

The system checks whether the device is plugged in before going from Wait to CheckPlugin mode. We 
have variable V olt as the guard for the three transitions: Plugin, Unplug and RePlugin. At each transition, if 
the guard conditions are meet, the corresponding transition wall be taken, and the variables will be updated. 

In the initial state, if the device is plugged in and receiving a voltage greater than 10 volts, the transition 
Plugin will be taken and Pluggedln wall be set to true. The plug monitor wall stay in the CheckPlugin state 
unless the voltage drops below 9 volts. In that case, it will enter CheckUnplug state and Pluggedln will 
be updated to false. Once the device is replugged in and receiving more than 10 volts, it wall reenter the 
CheckPlugin state. The monitor it will keep running in this loop indefinitely. Here, the Plugin Monitor is 
correctly and clearly modeled in DOV E. 

However, the Plugin Monitor is just a simple example of modeling a system. Life is not always so easy. 

W hen dealing with a bigger project in which some models wath interaction wath each other, some problem 
comes up. The ValueOk monitor is a component in which the variable ValueOk shows the status of the value 
variable. The state machine of Value Monitor is showed as Figure 2. The three states Wait, Check ValueOk 
and Check ValueFault are defined in the Value Monitor state machine. Six transitions connect these states 
and update variables if the guard of the transition is satisfied. 

In the initial state of Wait, once the variable Pluggedln becomes true, the variable ValueOk will be set to 
true. The device will enter Check ValueOk state. This can happen in one of two ways. When the system being 
monitored first starts up, the Plugin Monitor and the Value Monitor synchronize on beginning to monitor 
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Fig. 1 . A simple plug monitor in DOVE 
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their states Thereafter, if the power drops below a certain threshold, then the Yalue Monitor idums , to 
its Wait state and reenters Check ValneOk when it detects that the Plugin Monitor has detei mined that 
the power has returned to an acceptable level. Once in the ChecYalueOk state, if the input vaiiable Test is 
shown to he below 5. ValueOk is set to false, the device will enter the ClieekY alueFault state. If tunable T s 
is set back to greater than 5. ValueOk is set back to true, and the ClieekY alueOk state will be roen. ”” ‘ 
In both ClieckValueOk and ClieekY alueFault states, if the device is unplugged, the device will go 

Betwwn These two models, the ValueOk Monitor uses the Pluggedln variable, which is written by the 
Ph “ as an input variable. Unfortunately, with the current DOVE tools, these two interactive 
S^^d not be composed into one single model. In order to conquer this, we need to extend 

DOVE with product automata. 


3 Formal Definitions of Automata and Products 


In this section we will give a formal definition in higher-order logic of the type 
in DOY’E, their semantics of execution, and how we extend this with product 


of finite state automata used 
automata. 


3.1 Finite State Machines 

Informallv a finite state machine is a tuple of a set of states, a set of labeled transitions, and an initial 
state In DOVE the states are augmented with memory when executed. A transition is a directed edge 
between a pair of states coupled with a guarded action to be committed when that transition is execute ■ • 
The transition mav be executed onlv in the case that the guard holds in the memory of the- originating state 
of the transition and in which case the action yields the memory of the terminating state. Memory is 
association of values to variables. The guards are expressed as propositions over the variables in the memory 
and the actions are expressed as assignments of values (given as expressions over the memory s variable) 

th °™sToHon of finite state machine (or automaton) is similar to those discussed in the literature, and a 
typiclTexampl can be found in Chapter 4 of [4], One way in which DOVE extends tins notion is by segre- 
gating the variables into two categories, in which DOVE are referred to as input variables and heap vmahlcs 
Input 8 variables are read-onlv in that no transition may alter their value's. Their values are conside red to 
supplied bv the environment. As such, when defining an execution, we must assume that their yahms ma> 
change at anv point during a sequence of transitions. While this is manifest m the proof rules in Isabel), for 
proving temporal formulae for state machines defined in DOVE, it is a subtle point which complicates the 

definition of an execution arid warrants highlighting. , • . r k 

When a user defines a finite state machine in DOVE, they do so using a graphical user interface. This is 
used to generate a description in Isabelle of the finite state machine and properties that the user ^shes tc 
prove This description of the finite state machines in Isabelle is a shallow embedding m the sense that he 
variables of the fiiiite state machine are modeled as variables, as opposed to introducing a separate syntax 
for variables (in the form of a distinct type of variables). Such a light-weight embedding is advantageous 
when the' goal exclusively is proving properties in the model. However, it limits the ability to express me 
properties^in t he logic , such L stating what a finite state machine is. or what the product of two finite state 
machines is Therefor,', in this section, we will adopt a deeper embedding. The definition we will give has 
been rendered in higher-order logic. However, as in the informal description above, it is desirable to express 
things^using set-theoretic notation. In all formal definitions below, such set-theoretic notations should 
interpret eclats using a standard rendering of naive set theory in higher-order logic, such as one given by sets 

^ *ln attempting to formally define what a finite state machine is, we have to decide how to represent the 
writable variables versus the read-onlv variables. Our ultimate goal is to define a product for composing 
automata and in such a composition variables which may be read-only in one component may need to be 
writable in some other. Therefore, we will represent these two classes of variables as disjoint subsets of a 
single type of variables. For our purposes, the precise type used for representing variables docs not matter 
so we wUl use a type variable for this, allowing it latter to be specialized to integers or strings or perhaps 
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some other complex structure. Having made this choice, we will need to be able to express the requirement 
on transitions that they only involve the variables associated with the particular finite state machine. We 
will rapt me this notion of restricted dependence by the following definitions; 

same.on dorri f g = V x.x € dom => (f x = g x) 

That is. two functions art' the same on a given domain if they have the same values on all elements of that 
domain. 


/ only_depends_on ,s* — V ni\ /n 2 . same^on s Tii[ m> => (/ w\ — f 7 //■?) 

A function on functions only depends on a subset s if it always returns the 1 same value when applied to 
functions that are the same on ,s. The 1 motivation for this definition is that our memories art' functions 
assigning values to variables, but the guards and actions are only allowed to depend on that part of the 
memory that corresponds to the writable and read-only variables. 

A transition is well-formed with respect, to a set. of writable variables and a set of read-only variables 
provided that the guard and actions depend only on the union of the writable and the read-only variables, 
and the action does not assign any new values to the non-writable variables. 

is_transition ( state\ » states, guard, action) writable. vars read. only wars = 
guard only_depends_on (writable. vars U read-only wars) A 
action only_depends_on (writable. vars U read. only wars) A 
V memory var. (-1 (var G writable wars)) => 

(actum, memory var = memory var) 

We are now in a position to give a formal definition of a finite state machine: 

is_fsm ( states , labeled-transitions , writable wars, read. only .vars, 
initial .state , initial wonditian) = 

(writable wars D rcad.cmlywars — 0) A 
(V ( ( -s 1 , S'2 , g , a), l) G labeled Jransiti oris. 

is-transition(.s*] , .s 2 , g. a) writable. vars read-only wars A 
S[ 6 states A .s 2 G states) A 
(V (tiJi) G labeled Jr an sitions. 

(V (£2^2) G labeled Jransiti ons. (I i = Z 2 ) =^> (t\ = Z 2 ))) 
initial estate G states A 

initial condition, only.depends.on writable wars 

A tuple of states, labeled transitions, writable variables, read-only variables, initial state, and init ial condition 
is a finite state machine if 


the writable variables and the read-only variables are disjoint. 

— the transitions are well-formed with respect to the writable and read-only variables, 

— the stait and end states of each transition are among the states of the machine, 

— each transition label occurs at most once 

— the initial state is one of the states of the machine, and 

— the initial condition only depends on the writable variables. 


3.2 Executions 

Lp to now we have defined what it means to be a finite state machine; we have in effect described its syntax. 
We are still left with describing how to execute a finite state machine; that is, we are left with describing its 
semantics. The semantics of a finite state machine is the set of all its executions. So what is an execution? 
Informally, it is a sequence of moves through the finite state machine starting from a memory that satisfies the 
initial condition of the state machine, and then follows consecutive transitions. More formally, an execution 
is a pair of initial memories and a sequence of pairs of labeled transitions and resulting memories, where the 
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, Iar , „f vad, transition is stain .if t!.<- previous transition ami earl, transition is «IWb «* 

nrnvions men, pry ■. However, this is not a complete tlosrription. We n.ietl to ..ore proviso ahont what 

mean liv “resulting memories’ and "enabled by the pre\ious inemoiy . 

Dove is on! v capable of dealing with properties that are provable in finite time (safety 
will nse lists for Jpienees. It woltl not he frmtlante, .tally tlitferenl ,( we extentlerl to both (ante and mhmt, 

sequences. „ . . 

For the sake of readability, we shall make a couple of short definitions. 

(Iast_state initial state [] - initial state) A 

(last .state initial state (CONS (((s, ,s-.,g, a). 1), memory) :: seq) = *•>) 

The last state in a list of pairs of labeled transitions and memories is the initial state if the list is empty, 
and otherwise is the end state of the transition at the head of the list. 

(last memory initial jne.mory [] = initial Jin inot y) A 

(last-state initial-memory (CONS (((*,, .s 2 . t ,.a).l),memory)seq) = memory) 

The last memory in a list of pairs of labeled transitions and memories is the initial memory (for the intended 
execution) if the list is empty, and otherwise is the memory at the head of the list. 

‘ An execution in a finite state machine starting from an initial memory is a list of pans of labeled 
transitions from the finite state machine and memories such that 

- either the list is empty or 

• the tail of the list is an execution 

• the last state of the tail of the execution is the start state of the next, transition 

. the guard is enabled in some memory that is the same as the previous end memory on the writable 
variables (we allow the read-only variables change) and in that memory we execute the action 
acquire the new memory. 

is-execution [state. s, transitions, writable. vars, read-only -vars. 

initial state, initial condition) initial-memory con fry list = 
is_fsm (.states, transitions, writ able .ears, read-only -vars, 
initial .state, initial sondition) A 
initial -condition i nitial -memory A 
[(con fig list — [ ]) V 

(3 s-2 guard action l memory tailseq. 

(con} ig list. = (CONS (((s l ,s 2 ,giiard, action), l),memory)tailseq)) A 

is_execution tailseq A 

((,<>* j , s 2 s guard, action), l) G transitions A 
(last_state initial state tailseq = * 2 ) A 
(3 mem. same.on writable -vars mem 

(last_memory initial state initial -memory tailseq) A 

guard mem A 
action mem = memory 

We do not intend to go into the details of the particular linear temporal logic used in D « V E in tins 
paper but brieflv a finite state machine is said to satisfy a given linear temporal logic formula, provided 
everv sequence of memories derived from the executions of the finite state machine satisfies the formulae. 


3.3 Product Automata 

Having defined the syntax and semantics of finite state machines, we are in a position to give thedefimtton 
of the product of two finite state machines. Using the labels on the transitions our produc will aUow 
synchronization of transitions having the same label. The states of the product is the sutee of 
of the states that occurs in the set of transitions of the product (together with the produc t of the two initial 
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states, if it is not ahoady there). The transitions are effectively the merging of those transitions from the two 
automata that have' the same label, unioned with the remaining transitions lifted to the product states. We 
have to take a little rare to generate distinct new labels for the transitions. The writable variables are just the 
union of each set of writable variables. The readable variables are the union of each set of readable variables, 
minus am that are in the union of the writable variables. The product automaton will only be defined in the 
case where the writable variables of each are disjoint. The variables that are in the intersection of the union 
°f ^ ie writable variables and the union of the readable variables are those that are communicating values 
between the automata. The initial state is just the product of the two origin initial states, and the initial 
condition is the* intersection of the original initial conditions. 

Let the states of a transition lx* its start state and its ending state. 

statesof ((stutci , state?. guard, action), label) = {state instate?} 

The product is defined as 

wears i n wvars? — 0 = — > 

fsm.prod (states i , transitions [, wvars \ , rvars \ , init state .] , iiiitsoiid ] ) 

(states?, transitions-), wears-?, rears?, init, state-?, initjetmd-?) = 
let prod Jr an s — 

{(((' s ‘i * ft?), (*', . (hn.fji rn A g?m), a\ o a?), (/, NONE, NONE)) | 

((«i • . g i . «i ). /) € transitions i A 

( (s 2 , si 2 , g- 2 , a ? ), /) E transitions ? }U 
{ ( ( ( « S T , * 2 ), K , ),9 . «), (/, NONE, SOME s-?)) \ 

(* s i ? A “i - 9- a ) €. transitions \ A ->3 t.(tj) E transition s-)}u 
{ ( ( ( i (* s i , s 2 ), < 7 , a), (/.SOME s! , NONE) | 

si 2 , g,a) E transitions? A ->3 £.(£,/) E } 

and 

prod-states = {(init state \ , init. state?)} U U statesof / 

t€prod-trans 

in 

(prodstates, prod Jr an s, wvars \ U wears ? , 

(rears! U rears 2 ) - (wwarsi Uemars 2 ), (initstate x , init state?), 

X rnJnitjcond] m A init-cond? m) 

It follows from this definition that the product of two finite state machines is again a finite state machine, 
provided their writable variables are disjoint. Note that if the writable variables the first automaton are 
disjoint from the second automaton, then a.\ o a? — a?oa x (for all a\ and a? in the definition of the transitions 
in the product automaton above). Therefore, the product of two automata in one order is isomorphic to the 
product in the other order. 

Given an execution sequence, we can project that execution sequence to an execution sequences of of 
each of the component automata. 

(proj] (states i , trans \ , wvars \ , rears i , init state ] , init-cond ] ) [] = []) A 
(proj i (states ] , trans\ , wears j , rears ] , init state \ , init-cond ] ) 

(CONS ((f,/),mem) tailseq) =■ 
if 3 t f , ( t\l ) E trans\ 

then CONS (((choose t* . (f.l) E trans \ ). /), mem) (proj] tailseq) 
else proj\ tailseq 

We can prove that if a given initial memory and sequence of transition-memory pairs is an execution of 
the product automaton, then the same initial memory together with the projection of that sequence is an 
execution of the corresponding component automaton. Therefore, for every sequence of memories derived 
from an execution in the product automaton, there exists an almost, identical sequence of memories derivable 
from a sequence in the component automaton. (The original sequence may have additional memories that 
are the same as their immediate predecessors in the sequence on the writable variables of the component 
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automaton.) Therefore, for an appropriate class of temporal logic formulae (those that only involve the 
writable variables of the component automaton, and are "stuttering invariant), if a formula, holds of th 

H autnnialically a,» hoi, la of » b - M* 

on this system to be able to incorporate this into DON E. 


4 Extending Dove with Products 


In the previous section we described the mathematics of the product of two automata In this sc.uion wc ' 1 

discuss our method of implementing the construction of product automata as an 1 ' ^ content* 

current annroach is to add an external tool that can parse hies produced In DON E, analv/.c ti c com nt 
of those files to determine the details of the component automata to be composed construct the- pioduc 
autcnnatoii, determine layout information for it. and finally output all this information mto a new file that 

Call InTcm!^ STdOVE session, various local files are c reated, such as an smg file, a thy file, an nw 
file etc The smg file, which stands for “state machine graph" file (for example, plugin smg), contains aU 
of the information required to describe the finite state machine. This file inc ludes not only the 
and layout information about the state machine graph, but also the information to define variables, stat 

mrulitinns and transitions botwoon states. . , 

An smg is a sequence- of lines, each beginning with keyword, followed by data relevant to t he i J'm bemg 
added Firstly the smg file gives some preferences for display of the state machine. The global 'ana > 
gridOn tells us the canvas is gridded by being set it to 1, and not. gridded by being set it to 0. The- 'ana » 

smg j^^U^ned^ing the keyword f ile JlestoreNode follow the 

node coordinates and node name-. For example, in the plugin state machine graph file, wc define the 

state by 

f ile.RestoreNode 0 {20.0 10.0} Wait 

The node number of Wait is 0 and it is located at (20.0, 10.0). The edges in the plugin smg file are created 
bv the keyword f ilehestoreEdge followed by edge number, the number of the starting node, the mnnbe 
S .Mr dirnrti 1, sonic coordinates it travels through, an, the loeatron of the label and 
its name. For example, the edge Plugin iu the plugin smg file is defined as follows. 

fileJtestoreEdge 0 0 north 1 south {{20.0 13. 0» {{20.0 11.0} {20.0 
12. 0} {20.0 13.0} {20.0 14.0} {20.0 15.0}} {20.0 13.0} Plugin 

In this example, its edge number is 0. it comes ou, from north of node 1 ami g, ms hue , the south of node 

1. its label, Plugin, is at (20.0. 13.0), and it travels through the path of [(20.0, 11.0), (20.0, 12.0). ( . . 

13 Thfsilg file } gives two Ninels of variables, heap variables and input variables. The heap variables are 
defined using the- keyword dvd.def. It is followed by information about their names, types status and son 
comments on them.' Also wo define input variables by div_defs followed by the same information 

definition of the transitions, the smg file use dtr.defs. It gives a list of all the transition, 
followed by details of individual transitions. These details include the comments, status and the content 
the transitions. The content of transition has guard and act definitions m it.. 

Also it should have an initial state which is defined by the variable di.startStatea vahio. Th c mtad 
condition is given by setting the variable di_predicate. And we can add some comments on the initial state 

b ' In "acldh ion^tlu^smg file- c ontains some optional information about the finite state machine. For example 
if the state machine ll been checked and there is no syntax errors, the variable dchk.smgChecked is set to 

From ^all ^information above, we already know enough information tomM new s^g 

Any modifications of the smg file will directly change the state machine m DONE. Bv creating a smg 
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fil<\ wo can generate a now finite state machine without starting up the DOVE. We can construct the finite 
state machine to which is the composition of more than one component in one model without the need to 
interact with DOVE. 

I sing the above* information, we must parse the sing files of component automata to extract information 
to reconstruct the automata. Once the automata have been reconstructed, we must build the product au- 
tomaton. For this we* follow quite closely the mathematical description given in the previous section. SML 
data types and functions may ho used to compute the constructions previously given as mathematical for- 
nmlao. Once the product has been constructed, we still need to generate layout, information before we can 
generate a smg file to add the product automaton to DOVE. 

In DON E, layout information is generated from interactions with the user. The user places nodes at 
various ^rations on the drawing canvas and draws edges between the various nodes, indicating curvature by 
tin' path of the mouse. The layouts may he altered clicking and dragging the various entities to be changed. 
DON E does some work to generate a decent presentation of the graph, but the basic layout information 
comes from the user. When we automatically generate the product automata, we must also automatically 
generate some positioning for the components: to make the user generate this information would be almost 
tantamount to making the user create the product in the first place. To generate this information, we make 
use of the graph visualizat ion tool dot. ([3]). Dot is applied to a file that lists the nodes and edges of a directed 
graph, together with any desired labellings of the nodes and edges, and the desired shape (and color) of the 
nodes. The following is an example of a part of an input file for dot for the produet, of the two automata 
given in Section 2: 

digraph G { 

n8 [label = ”CheckPlugin_Wait " , shape = circle] 


n4 [label - "CheckPlugin_CheckValueOK M , shape = circle] 

nO [label = "Wait .Wait" , shape = circle] 
n8 -> n4 [label = PlugOK_atl_CheckPlugin] 


nO -> n4 [label = "Plugin"] 


} 

Dot. then generates a layout for the graph and out puts it in one of several formats, including gif and 
postscript , for example. The mode we used is an expanded form of the same language used for input, where 
layout coordinates have been added. The above graph description is translated to: 

digraph G { 

node [label="\N M ] ; 

graph [bb="0, 0,2211, 516"] ; 

n8 [label=n8, shape=circle , 


n8 [label=CheckPlugin_Wait , shape=circle , height="0. 56" , 
pos="1128 ,488" , width="0 . 56"] ; 


n4 [label=CheckPlugin_CheckValueOK, shape=circle , 
height="0.56", pos="1028 ,212" , width="0 . 56"] ; 

nO [label=Wait_Wait , shape=circle , height="0 . 56" , 
pos="1709,304" , width="0 . 56"] ; 

n8 -> n4 [label=PlugOK_atl_CheckPlugin, pos="e, 1048,214 
1139,471 1165,429 1223,318 1171,250 1156,231 1092,221 
1055,215", lp="1270,350"] ; 


nO -> n4 [label=Plugin, pos="e , 1048 , 213 1692,293 1685,289 


Extending DON E with Product Automata 


111 


1679,285 1675,284 1557,244 1168,219 1057,213", lp-" 1633 ,258"] ; 

} 

For each node, the size (height and width) of the circle, anti the posit ion of its center is added. Each edge is 
extended with path information, consisting of the position and direction of the terminating arrowhead follow 
by a sequence coordinates that the edge will pass through, and with the coordinates of the left edge, of the 

lab We m ust parse the information returned from dot and combine it with the non-graphical information . for 
the product, automaton (such as the guards and actions for each transition). Alsm the graph 
produced bv dot. is not completely suitable for directly inputting into an smg hie. We need to pet form scab g 
and better layouts seem to be given by thinning the points for layout of the transitions. Once we adjust th 
information from dot and combine it with the non-graphical information, we can finally produc an smg hh 
that describes the product automaton to DOVE. Once this file exists, the user can start up DON E with it. 
and proceed to state and prove properties about it . 


5 Future Work 

The work described in this paper outlines a way to build the interactive components into one finite state 
machine bv extending DOVE with product automata. By using the information we get from parsing the smg 
file in DOVE we can create a new state machine graph file by hand without disturbing DON E. rogi anmnng 
to perform all of the steps indicated in Section 4 is not yet finished and tested. We anticipate having a 
completed prototype by the time of the conference. 

Once the product automata is built, we also need to test its correctness and feasibility Wc begin _ tins 
project because we were attempting to use DOVE to reason about a medium-sized real-world safety-critical 
system This system could be naturally decomposed into a hierarchy of subsystems communicating through 
limited intefaces of input and output variables. In attempting to use DOVE, we found ourselves attempting 
to compose these subsystems by hand. With the completion of this tool, we will return to this example and 
use DOVE to describe this hierarchy and complete the task of proving the required properties. 

‘ As described in this paper, we are adding a tool to DOVE that will allow for the automatic construction 
of product automata from component automata. However, there is more that we desire. At the end of 
Section 3 we indicated that the mathematical theory underlying the product automata should alloy us 
to automatically translate properties that hold of an individual component automaton to corresponding 
properties of the product automaton. DOVE should be extended to support such a feature The user shou 
be able to reason about the various components and then have those results automatically earned over to 
the product, when the product is formed or its theory is subsequently updated To support this with the Tull 
rigour currently available in DON E, we would need to be able to prove in Isabelle that the product that wc 
have externally created is indeed the product as mathematically defined. To be able to prove such a 
requires a deeper embedding of finite state machines in Isabelle than is currently used. Therefore, adding 
this extension would require a siginficant reworking of the foundations of DONE. It is our opinion that the 
benefits would merit such an effort . 
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Abstract. This paper introduces the topic of metabolic pathways and explores it as a subject for 
study by the theorem-proving community. A description of the issues involved is provided, as well as a 
justification of why a logic-based description of these pathways might complement the current progress 
in the area of Bioinformatics. 


1 Introduction 


Bioinformatics is the application of computational methods in the understanding of biological systems. 
T\ pit ally, it involves analysing information stored in large databases; the information itself is obtained from 
experiments. 

The processes of gene expression and protein function are schematized in Figure 1. Bioinformatic research 
on these processes has given rise to three sub-areas: 

genomics is the deciphering of the code contained in the DNA, that is knowing what the actual strings are 
and which genes exist; understanding how the code of the DNA is actually expressed 

proteomics is concerned with understanding the functioning of proteins, which structurally are the products 
of DNA translation and functionally are the active agents of life, whether as enzymes or channels or any 
other way. 

metaboiomics studies the biochemical processes that occur within cells, and the complexities of control 
that make living organisms. 

Each of these topics of research has given rise to a large variety of formalisms developed by often competing 
groups. An important issue is finding the right abstraction which allows the different tools to work. Each of 
these systems has its own language. 1 discusses the fragmentation of bioinformatics protocols, technologies 
and standards, that together created a landscape of confusing and poorly integrated web sites and other 
services, and suggests that the solution may be a formal model to unify these languages. 

The success of research in genomics can be attributed partly to the use of a very simple abstraction, namely 
the four letters A,T,C, and G organised into substrings (the genes), which are then strung together to form 
chromosomes. Similarly, proteins are formed from a larger alphabet of amino-acids. A paper by Giegerich, 
Hinze and Kurtz [3] presents a small model of DNA/proteins in Haskell (Figure 2). Note that this description 
of the process of DNA transcription does not scale up to the 

However, when we come to proteomics. we start encountering difficulties, as there is no simple representation 
for the shape of proteins, and it is still not possible to predict the shape of a protein from knowing its chemical 
structure. 

Metabolism can be seen as a complex network of reactions depending on the interaction between many 
different kinds of molecules. The primary actors are enzymes - proteins that facilitate reactions. Here also 
there is a problem with finding the appropriate abstraction for representing the biological system. Graph 
theory is usually part of the model, and there are different programs for displaying graphs in a pleasant 
fashion on a 2D screen. However, the additions that need to be made to the graphs are: 

j Research done partially while author was a Visiting Fellow at the Australian National University. 

See http://www.oreillynet.eom/puh/a/iietwork/2G02/01/29/bioday2.html 
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Fig. 1. From DNA to protein function (from www.people.virginia.edu/ rjh9u/trtrpict .html) 
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data Nucleotide = A I C | G ) T 

data AminoAcid = Asn | Lys I ... — and so forth (aminoacids) 
type DNA = [Nucleotide] 
type Protein = [AminoAcid] 

type Codon = (Nucleotide, Nucleotide, Nucleotide) 
genCode : : Codon -> AminoAcid 

genCode (A, A, A) = Lys; genCode (A, A, G) = Lys; 
genCode (A, A, C) = Asn — and so forth 

ribosome : : DNA -> Protein 

— the ribosome always starts at ATG 
ribosome (A : T : G : x) = Met : map genCode (triplets x) 

triplets [] = [] 

triplets (a : b : c : x) = (a, b, c) : triplets x 

wc_compl A = T ; wc_compl T = A; 
wc_compl C = G; wc_compl G = C 

complSingleStrand [] = [] 

complSingleStrand (a : x) = wc.compl a : complSingleStrand x 
dnaPolymerase x = (x, complSingleStrand x) 

Fig. 2. Genomics in Haskell 


- classes of chemicals 

- classes of reactions 

- inexact matching of graphs 

The data needs to he stored in a rich formalism. The number of macromolecules, reactions, combinations, 
etc is huge. The analysis needs to take into account these interrelations between entities. In this paper we 
explore the use of higher-order logic to represent and manipulate metabolic information. 


2 Biochemical reactions and enzymes 

A metabolic pathway is a sequence of biochemical reactions. These reactions are rigorously controlled by a 
complex mechanism, in order to maintain balance within cells. The most direct form of control is through 
a catalyst Catalysts are not consumed by a reaction, so that once a molecule of the catalyst facilitates 
a reaction, the products are produced, and the catalyst molecule is released back into the environment, 
potentially allowing it to facilitate another instance of the reaction. Theoretically, the reactions would still 
proceed in the absence of the catalyst, but in a slower rate, sometimes close to zero. It is useful for biochemical 
reactions to depend on catalysis, in order to provide control mechanisms. 

Most chemical reactions have a hidden component: the energy involved. In inorganic media energy is mutated 
into heat, but in living organisms it is stored into complex molecules, which serve as a buffer. Cellular energy 
management, is based around pairs of related molecules, where one contains a substantial amount of energy 
compared to the other. Typical pairs are ATP and ADP (Adenosine Tri and Di Phosphates), GTP and GDP. 
and NAD+ and NADH. When energy is required for another reaction, the high energy molecules are used, 
and replenish the stock of low energy molecules which then are used when more energy is released elsewhere. 
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There are other sources of more concentrated energy as well, e.g. in the form of lipids, hut these 
to release. This energy is first transferred into ATP/GTP molecules which are then used an situ. 


take* longer 


Typically one direction of a reaction releases energy while the other consumes, or stores energy. Most reactions 
are theoretically reversible, hut the difference in energy means that one direction is favoured over another . 
Furthermore, even if a reaction ultimately releases energy into the medium and is favoured, it often needs 
a lot of energy to be started. Catalysts often work by reducing the energy required for a reaction to occur, 
and thus ran increase* the rate of reaction. 


While catalysts can be of out' of many types, enzymes are' catalysts primarily made up of proteins. Typically, 
an enzyme facilitates a reaction by slotting reactant molecules into particular spaces and thus bringing them 
into close proximity and at the right spatial relation so that the reaction can occur: once this happens t le 
product molecules are released into the environment and new reactants occupy the now vacant spaces close 
to the protein. 


2.1 Classification of enzymes 


Enzymes are a large group of proteins; enzyme list from 1992 contains 319G live entries. With such a large 
number it is important to classify them in a meaningful and useful way. The most accepted method of 
classification of enzvmes is provided by their EC number. This is a strictly functional classification, based 
on 4 numeric fields [1]. The first field specifies the kind of reaction the enzyme catalyzes, while the second 
one describes the active atoms involved. This is illustrated in Figure 3 


1. Oxidoreductases 

1.1. CH-OH 

1.2. OXO 

1.3. CH-CH 

1.4. CH-NH(2) 

1.5. CH-NH 

1.6. NADH/NADPH 


1.7. N compounds 

1.8. Sulphor 

1.9. ... 

2. Transferases 

2.1. 1-car bon group 

2.2. ketone residues 

2.3. acyl 


2.4. ... 

3. Hydrolases 

4. Lyases 

5. Isomer ases 

6. Ligases 


Fig. 3. Classification of enzymes 


It should be remembered that this classification is functional, and the information is usually derived from 
biochemical experiments. But enzymes should also be understood to be essentially proteins, produced by 
the translation of a gene and then the activation of the protein by taking a particular 3-dimensional shape, 
which is a consequence of interaction of its particles with each other and with the environment . Correlating 
a known enzyme function to a particular gene is a matter of intense research in the field of bioinformatics. 

As an example, one may look at a particular place in the EC classification: EC 1.1.99 consists of nialate 
dehydrogenases. But there are many malate dehydrogenases, from different organisms. EC 1.1.99.16 repre- 
sents a variety of proteins, io NCBI 1788539 on E.Coli and NCBI 2078007 in P. Aeruginosa. A comparison 
of the sequences reveals that they are of different size and are of different sequence so how do we know 
they are the same enzyme? An ortholog cluster is such a group of functionally related enzymes, one from 
each organism, which can be postulated to have a common origin. Confirmation of this link can be partially 
obtained by applying string matching algorithms, but this is inadequate because the relation between dif- 
ferences in the aminoacid structure of proteins and their functionality is not linear. Another approat i to 
correlation of enzvmes lies in understanding the pathways in which the enzyme is used. The understanding 
of these relations is crucial for several of the applications of bioinformatics, such as understanding etiology 
of diseases and aiding drug design. 
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3 Understanding metabolic pathways 

A pathway consists of a. sequence of biochemical reactions. Pathways can be classified into several types: 
synthesis, degradation, and energy transfe. Each of these pathways is made of reactions that can be classified 
in a way similar to the enzyme classification of Figure 3. As many of the molecules in a pathway are recycled, 
quite often pathways are shown as cycles, specially when one of the recycled elements is of larger complexity 
than some of the products, or when it appears in very few other pathways. 

Out 1 of the most well known pathways is what is known as Kreb’s cycle, or TCA cycle, illustrated in Figure 4. 
This pathway is shown as a cycle' because a Citrate molecule is regenerated each time, which is then used 
in successive reactions to yield high energy NADH and GTP molecules. The citratemolecule is a product of 
the iea( tion of oxaloacetato with acetyl Co A (co-enzyme A) which is the produetderived from “burning” of 
sugar. One may note the presence of several enzymes (indicated by the -ase suffix) which drive this cycle. 

Metabolic networks are very robust, due to several factors: 

T failure of an enzyme due to a structural change is not always catastrophic, in the sense that impairment, 
of an enzyme’s function can be partial; 

2. if a particular enzyme is non-functional, other enzymes which otherwise have only a weak action can he 
modulated to have further effect, as many enzymes can work on different pathways; 

3. there may be several pathway variants : similar functions using different reactions and routes, whicii can 
continue ellular function in a reasonable manner. 

W ithin a natural environment, a pathway does not occur in isolation, hut is part of an elegant, complex 
system [6], where molecules are resources that are shared between many processes, or which are made available 
through diffusion or membrane transport mechanisms. Also, innumerable instances of reactions from different 
pathways occur simultaneously and in close proximity, and the balance between the concentrations of all 
these elements is intricate. The separation into individual pathways, and the concretization into individual 
molecules, is merely didactic. 

Furthermore, one needs to take into consideration the compartrnentalization of the environment through 
permeable membranes. Proper cellular function is tied to the mechanisms for transport of molecules — 
whether through simple diffusion or across a membrane (between the cytoplasm of a cell and its environment 
or between the cytoplasm and the nucleus or organelles such as the invtochondria) through channels . Quite 
often proteins art' involved in these transport mechanisms, and they art' subject to control strategies similar 
to the control of reactions. 


3.1 Other biochemical networks 

Metabolic pathways are just one type of biochemical networks. Other networks are gene regulatory networks 
and signal transduction networks, which make sure that the biochemical reactions occur at rates that are 
beneficial to the organism, depending on extra-cellular factors as well as internal feedback mechanisms. 

A simple form of control for enzymatic catalysis is the control of the production of the proteins from DNA. 
The more proteins are created and activated as enzymes, the higher the rate of reaction. By stopping the 
production of enzymes, eventually the concentration will bereduced, and the rate of reaction will decrease. 
However, the process of protein production may be slow, and the rate of natural degradation of proteins might 
be extremely slow, so other mechanisms have evolved, such as signal transduction networks and hormonal 
signalling. 

As well as having more short-term control of metabolism, organisms also need to perform long-term control. 
One particular method of control is through the use of regulons , which control groups of operons which 
control gene groupings. Global regulons coordinate regulation of operons in multiple metabolic pathways, 
other global regulators act through control of DNA spatial configuration. The biochemical logic in genetic 
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Fig. 4. The TCA cycle (from http://chemistry.gsu.edu/glactone/PDB/Proteins/Krebs/Krebs.html) 
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regulatory circuits provides real-time regulatory control, which can he seen as a branching decision logic, 
executing stored programs that guide cellular differentiation extending over many coll generations. 


4 Representing metabolic pathways 


In this work we are interested in developing suitable representations for the kind of information described 
above. Representing this kind of information in a plain, first-order system doesn't capture the true richness of 
the domain, because biochemical processes are characterised by their generality and adaptability, as well as 
the inter-relationships between the many entities. Several open research problems such as discovering evo- 
lutionary relatedness, finding alternative pathways, and predicting shape 1 from sequence depend on finding 
these relationships. 

Many database's of metabolic information have been developed and are in widespread use* by biologists and 
biochemists. While ideas of object-orientedness and subclassing mechanisms are sometimes exploited, several 
of the languages and techniques are quite ad-hoc, and many of the features that could be implemented by a 
good type system are currently processed through extensive explicit, programming. We next introduce some 
of these systems, and then present a vision for a more appropriate representation. 


4.1 Existing technology 

Biochemical dynamics arc? sometimes modelled quantitatively, in order to capture the situation. A popular 
model is the e-Cell [10], which represents a simplified cell in an object oriented language (C++) and allows 
experiments in which concentrations of molecules can be set arid observed at different (virtual) times. How- 
ever. there is still a lot that can be gleaned about metabolic processes from a purely qualitative model, and 
this is the approach taken by most of the existing systems. 

There are many databases with very impressive amount of information about metabolism, such as KEGG 
[4], METACYC [5], EMP [9], and UM-BDD [2], amongst others. Often these databases have grown from an 
attempt to use, organize' and share in-house data, and some? of the software tools have been developed with 
these aims in mind. 

KEGG (the Kyoto Encyclopedia of Genes and Genomes) is one of the best sources of data. It covers not 
only metabolic information but also what is possibly the most complete genome database. It is based on the 
DBGET integrated database, and is also linked with LIGAND (a chemical database for enzyme reaction). 

According to Peter Karp, the developer of MetaCyc, KEGG mixes information from different organisms. 
It also has no information about enzyme inhibitors or subunits, or substrate specificity. MetaCyc contains 
information about 4218 reactions organized into 445 pathways, obtained second hand from literature, and 
covers 12 organisms. MetaCyc stores super-pathways - groups of pathways linked by common substrates. 
Pathways are inferred using a module called PathoLogic. Some problems identified with MetaCyc are missing 
or incorrect information. 

WIT is a system for reconstructing metabolic networks based on EMP data [7], and it supports the use 
of phenotypic data as well as usual biochemical and genomic information. EMP bills itself as the most 
comprehensive source of biochemical data. The University of Minnesota’s UM-BDD focuses on bacterial and 
archaeal pathways, and the study of enzymes . The information is curated from different sources. Amongst 
all the databases, it is the one where the contribution from different sources, including KEGG and EMP, are 
acknowledged, and the importance of sharing information is raised. 

All these systems seem to work on the premise that metabolic pathways are graphs, ie lists of reaction pairs. 
The way each of these reactions, and the consituerit molecules, is stored and accessed is an engineering 
issue, but mostly they use a straight-forward database representation. However, because they represent 
‘large, noisy, complex data-sets and knowledge sets” (in the words of Peter Karp), there are bound to be 
inconsistencies and information of limited certainty. It seems sensible to apply some of the expertise of the 
theorem-proving community in developing a well-thought out representation for this knowledge. 
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4.2 Pi-Calculus models of bionetworks 

There is substantial work on models of biological networks by Regov, Priaini, et al. using Stodiastk Pi 
Calculus [8]. Reactions between molecule's are activated by the exchange of signals, and hiding is used to 
model specificity, and creation of intermediate' compounds. Their moelels are quite detailed, and capture 
numerical reasoning along with the qualitative description. It is unclear if the numerical results obtained In- 
naming the stochastic pi-calculus descriptions correspond to real-world data, and if the semantics of the two 
systems correspond to each other. Furthermore, the descriptions are given in great detail, but this detail 
makes it difficult, to get a clear picture and reason about the pathways in a structured fashion. And there 
is scope to explore families of reactions, something that, would be aided with the use of a richer type-based 
language, which better capture the general rules and polymorphic nature of metabolism. 


5 Use of higher-order formalisms 

While the databases that have been described above contain a lot of information about metabolic processes, 
one aspect they all seem to be lacking is an appropriate ontology for the system. The databases take their 
queue from encyclopaedias, which store information which must then be processed by the scientist who builds 
ontologies in an informal fashion. There are projects aimed at building ontologies for biosystems (such as 
the use of Description Logics for building the Tambis Ontology (TaO); these logics aim at improving the 
understanding of the way information is stored in the databases, rather than looking purely at the biological 
systems themselves. Typical ontologies use a small number of concepts, such as relations, instances, and 
axioms. 

The use of a logical formalism for describing metabolic data can move the paradigm for computational models 
of metabolism significantly. Rather than considering a database, where the power exists in the capture of 
a great amount of details and the existence ofvisualization and access tools, a logical model would offer 
simplicity and the power to add new information in a simple and consistent manner. Rather than testing a 
new model for a pathway as a now graph in the database, one could write it as a functional composition of 
possibly polymorphic functions, and reason about it within the established logical rules and deduce propertie s 
such as liveness of the cycle. 

Several formalisms which have been developed initially by logicians and later eagerly adapted by computer 
scientists for the purpose of describing computational systems are particularly suitable for capturing the 
workings of metabolic pathways: 

Temporal Logic: a system of inference rules that allows one to reason about the evolution of a system, in 
terms of eventual outcomes, invariants, ontailmcnts, and fairness amongst several processes. The goal 
is to know the outcomes of a process not by simulating it for a long (abstract) time but by analytical 
reasoning. 

Linear logic: a system of inference rules that allows one to model resources, and propositions that hold at 
one point and may not. hold at the other. One of the main simplifications of traditional inferenc e systems 
is that once a theorem is said to hold, it needs to be assumed to always hold; this makes it difficult to 
model transient properties inherent to biological systems. Linear logic solves this issue' by allowing some 
assumptions to be used only a finite number of times, which therefore makes it suitable for representing 
chemical processes. 

Type theory: simple data types do not capture the richness of groupings and dependencies existing in 
natural systems. Recent interest in object-oriented modelling shows that bioinformaticists arc’ keen on 
exploring new type systems, but object-orientation itself is more geared towards programmability that 
description. The’ interaction between quantification, subtyping, and polymorphism of systems such as 
F <: allow a richer desc ription of data. 

All these approaches can be implemented within Higher-Order Logie, and in fact several implementations 
in different proof systems already exist. New extensions allow the description of probabilistic- algorithms 
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and masoning about them. In this poster simple models of enzymatic pathways using all throe formalisms 
above will demonstrate the usefulness of these advanced logical systems to bioinformatidsts. This is work in 
progress, and it is expected that a second pass at a logical model that integrates the separate descriptions 
in the three formalisms above will bo developed. 
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Abstract. Extending the type theory of a logical framework with a proof irrelevance modality has 
several potential advantages, including the ability to represent subset types and invariants for proof 
compression. Although the extended theory is well-behaved, it is not yet completely clear how to modify 
the implementation of a logical framework to accommodate proof irrelevance. The unification algorithm 
in tiie logical framework Twelf. in particular, works by a process of constraint simplification that 
depends on the notion of pattern substitution. Adapting this algorithm to work with proof irrelevance 
requires generalizing the definition of pattern. We propose such a definition, guided by work with proof 
irrelevance and strictness, and make progress towards proving its correc tness. 


1 Introduction 

1.1 Higher-Order Pattern Unification 

Our starting point is an algorithm for higher-order pattern unification using explicit substitutions due to 
Dowek et al. [3]. The difficulties of variable capture involved in higher-order unification are avoided by a 
reduction [2] to first-order equational unification in a language with explicit substitutions [1]. This first-order 
algorithm specializes nicely for a decidable subset of unification problems, the pattern fragment. The strategy 
of constraint, simplification for solving general unific ation problems trying to solve equations which are 
in the pattern fragment and postponing constraints produced by those that aren't., which may later be 
resolved by substitutions arising from other equations - though not complete, has been found to work well 

in practice. 

Informally, pattern is a term where all the variables (by which we mean metavariables amenable to 
substitution) occur above a sequence of distinct deBruijn indices, i.e. bound variables. If all variables have 
atomic type (and we can easily transform problems to have this property) then this means each variable 
must occur under a substitution whose range is a set of distinct. deBruijn indices, a pattern substitution. 
Pattern substitutions are desirable because they have one-sided inverses, and so are injective. Equations of 
the form A"[C] = b therefore have at. most one solution, written 6[C] -1 - 


1.2 Proof Irrelevance 

Constants are naturally injective; if we have a constant c : r, -»■■■-+ r„ ^ t of n arguments, the terms 
c Mi ■ ■ ■ M n and c M{ ■ ■ ■ M'„ are equal if only if A/; = A// for all 1 < » < n. There are times when this 
is not the desired behavior. Sometimes we would like to he able to make certain arguments to a function 
‘irrelevant’ when it comes to deciding equality. This can occur when some arguments to a function are 
meant to be thought of as witnesses of provability rather than pieces of data whose structure matters. This 
phenomenon is proof irrelevance. Generally, suppose we use the following signature in the dependent type 
system LF ([4]): 

t, u : type 
p : IJx: t. type 
c : Tlx: t.TJy: (p x):u 
a : t 

bj>' : pa. 
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Intuitively, we have an object a of type t , and some predicate p on objects of type t. The function c takes 
two arguments: an argument x of type t, and an argument y of type p x (which might be thought of as a 
proof that p holds of x) and returns an object of type a. As the preceding discussion describes, c a b ± c a 1/ 
because not all of c's arguments are the same on both sides of the equation b and V differ. We would 
like to declare instead a d : Tlx: I .Fly 4- (p x).u, where the 4- symbol is supposed to be a promise that the 
argument y ‘doesn't matter' in the output of d. We proceed to discuss some applications of proof irrelevance 
in more detail. 


1.3 Encoding Subset Types 

The example above is really a trivial case of the use of proof irrelevance to obtain adequate encodings of 
subset, types , which can be useful when representing programming languages and logics in a logical framework. 
A subset type is a formal version of the common mathematical set-formation syntax {.r £ X | 0(j*)} for some 
predicate 0 on A\ As a typical example of its usefulness, suppose we wish to represent a lambda calculus 
which has a 'relevant 1 binder A- 1 which requires the variable it binds to occur at least once. We could try 
doing this by beginning with the usual untyped lambda calculus 


and defining a predicate 


via the logic program 


tm : type 

app : tm — > (tm — > tm) 
lam : (tm -> tm) tm 


occurs : (tm — > tm) — > type 


occurs_var : occurs(A;r.r) 

occurs_appl : occurs(A;r. app A/j M>) <- occurs(Ar.A/] ) 
occurs.appr : occurs(Ax. app M\ A/ 2 ) <— occurs( A.r. J/ 2 ) 
occurs Jam : occurs(Ar. lam(A/ x)) 4- (IJy: tm . occurs(\x.M x y)) 

which captures the* proposition that an open term uses its free variable, and declaring a constant 

olam : Fit : (tm — ► tm).77p : occursT tm 

However, because the binding of the proof p is the usual, “relevant” binding, this encoding is not adequate: 
There are generally multiple LF terms which represent a given object-language term. This is because there 
are potentially many proofs that a variable occurs bound in fact there will be one proof per occurrence 
of the variable. Therefore we want to equate all terms using olam that differ only in which occurrence proof 
they use. That is, we should declare instead 

olam : lit : (tm — ► tm). IJp -r occurs t. tm 

and the new encoding is adequate. Though the revised olam still requires the existence of a proof p that 
occurs t holds, it doesn’t care which proof in a certain sense, which is guaranteed by the type system. 


1.4 Subterm Omission in Proof-Carrying Code 

In a language like Java, some measure of safety of running code is insured by running the code ‘in a sandbox,’ 
inside a trusted virtual machine. Proof- carrying code [5] is another technique which aims to achieve the same 
(if not greater) safety properties without sacrificing runtime efficiency to emulating a virtual machine. The 
burden of making a program safe falls instead on the author of the program, the code producer. The recipient 
of a program, the code consumer requires a proof that the program received satisfies some safety policy, and 
so the code producer must send with the program a formal certificate of safety which can be mechanically 
checked by the code consumer to actually prove that the program won’t violate the policy. 
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Unfortunately those certificate's can sometimes he large, even on the order of the size of the mzp tl 
program being proved safe. Technic pit's for reducing proof size' are desirable. Although t he problem of tun hng 
\ P r 00 f for a given proposition is typically undecidable, a proof may have many subproofs tv huh could be 
easilv and efficiently reconstructed by the code consumer. For instance, as part of a large proof that slums 
that aerogram always computes a certain mathematical func tion correctly, it might be necessary to s ou 
I tSZt. s-iv 3 + 4 = 7. Now the formal correctness of this program depends on every last detail 

of the proof being correct, but there is no need to send a proof of 3 + 4 = ' a ‘ r(>ss th< ‘ I10t ^ < ”^ =- .! “ ” 
can simply be a blank spot in the proof with an instruction saying, "please check that m fac t 3+ ■ 

trade-off here- is saving network bandwidth by perhaps spending more time reconstructing proofs on the c oc 

"T^teL proofs arc froquomly roproson.crl as terms in a type theory Bko LF- 

like Tvvelf ([8]). Ill this case, the idea of omitting subproofs re-alb means omitting su > < mis. ‘ 

be addressed is when can a subterm be- safely omitted? Twelf already has facilities for providing sufhc i nt 

conditions for termination of predicates considered as logic- programs. When we can 

that searching for a proof of P (which is what is meant by “running the logic program P ) A \y>»U n 

and we know a proof of P. then we can be sure- that the code consumer can also find a proof of P. W hat vve 

do not know is that the code consumer will find the same proof. It may seem like- a desirable P^rty of a 

type system that if vve replace a subterm S of a term M with a different subterm S of the same v pc , the n 

M is still well-typed, but dependent types systems do not necessarily have this property exac t > >ee ause 

the dependence of types on terms. For example, in the signature 


a, 2 : type 
b : a -4 type 
c : FI x: a.(b x) 
d : Ux\ a.(b x) -> 2 
k\ , k 2 : a 


we have the typing 


•h (d.k x )(ck A ) :z 


but not 


h (d k\)(c k 2 ) : z 


even though vve- have only changed one subterm of type a to another. 

If vve introduce proof irrelevance, however, then it can be shown that replacing cme su ™ * 

irrelevant application with another preserves the whole term being well-typed. Therefore, it s safe to omit 
a subproof of a large proof if we can show that the subproof can be decidably recoveied (i.e. if the pr< < i - 
can be- shown to be- terminating) and occurs under an irrelevant, application. 


1.5 Extending Unification 

The- task before us is to modify the pattern unification algorithm to work in a language with proof . 
and in particular to find the right notion of pattern. A similar situation arises with the notion of • _ 
definitions [71 which depends on the definition of pattern spines. In the absence of irrelevance, a pattern 
spine- is again a list of distinct bound variables. In [9] we found a modification of the definition of pattern 
spine which satisfies the same critical lemma as the original, again an injectivity property The change 
made were adding an ‘irrelevant cons’ to the syntax of spines and requiring distinct bound variables 
-relevant' positions and allowing any term at, ‘irrelevant’ positions. We imitate these changes m a drfmtUon 
of pattern substitution, and observe that one-sided inverses again exist , for an appropriate notion of c qua 
of subst itutions. The theory here is simply-typed throughout, though vve expect an extension to full dependent 
types to be reasonably straight. for\v aid. 
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2 Syntax 

Wo define the Xa‘ -calculus, an extension of the typed Ad-calculus with term variables [1] to include proof 
irrelevance in the sense of [6]. For uniformity of syntax, we have a sort of modalities p with which we 
annotate function types, function abstractions, context and substitution conses, and applications (written 
o). The modality r refers to the usual (‘relevant’) notion from A-ealculus and i gives the ‘irrelevant’ version. 

Modalities // r | i 

Types ,4. D \\= a \ A ^ B 

Contexts r • | ^4 Jt r 

Terms «, b ::= 1 | X | (a o" b ) | A " A a | «[.s] 

Substitutions ,s. t ::= id 1 1 1 a J ‘ & j ,s o / 


3 Typing 

Then' are two typing judgments, 

Term Typing T b « A a has type A for modality p 

in the context r. 

Substitution Typing fhs: P s is a substitution for the 

variables of F ( in r. 

Note that the term typing judgment is also annotated with a modality. We abbreviate : r by : and by -y. 
The meaning of the irrelevant typing judgment is given by the context operation defined recursively 


(.4 •" r) e = .4 - r (r B ) 

and the rule 

r® b a : .4 
r hay.4 

r is the context. F with all irrelevant assumptions promoted to ‘real’ assumptions, so the typing rule allows 
us to conclude that a A .4 if we can derive a : A when we are allowed to use even irrelevant assumptions. 
The remaining typing rules are 


.4 r r b 1 : .4 A ■>' r b t : T 

.4 M r b b : B r b a : A -+>' B r b b F B 
T b A^ .b : .4 — B r b (a b) : B 

r b id : r 

r b s r' r' a a 
r b a[s] ■/ A 
r b s ; p r'\-p. r" 

rhtos-.r" 

r b ,s : P r b a . A 

r b a ■" s : .4 P 


Tv b V : 7 A 
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4 Reduction 

\V(> list a sot of reduction rules which arc a straightforward adaptation of those in \a, including those added 
in [ 1 ] (Id. IdR. VarShift. Scons I for critical pairs arising from the addition of term variables. 


Beta 

(A \.a)U 

-> (a[b Jl id]) 

Eta 

A'',, (no" 1 ) 

— » b if a fr[f 

App 

(a o ' 1 b)[s] 

(«[*] <> p M- s l) 

VarCons 

l[fl J ‘ s] 

— > a 

Id 

"[id] 

-> a 

Abs 

(A 7 »N 

^ A^(n[l-" (s 

Clos 

w*m 

— > a[s o t] 

IdL 

a 

o 

-> s 

IdR 

s o id 

-> ,s 

ShiftCons | o (" " ») 

-> ,s 

AssEnv 

(.S 1 O ,S-_) ) o 

.S3 -> .S \ o (.So 0 -S;y 

MapEnv 

(a •" a) o t 

a [t] Ji {so t) 

VarShift 

1 t 

— > id 

Scons 

IN -"(1° 

.s) — > s 


It remains to work out what, normalization and confluence properties this system enjoys. It seems likely 
that weak or strong normalization of any fragment should follow easily from the same property holding of 
the corresponding fragment, in the underlying calculus without irrelevance by a simple erasure of modality 
information. However, to whatever extent the property would depend on the tvpability of a term, we mig l 
encounter difficulty dealing with full dependent types, since erasing irrelevance from a dependency typed 
term may not result in a well-typed term. 

We might also consider adding a reduction rule 

Irrel a •* $ — > o' 1 s 

to capture the intended meaning of an irrelevant, cons, but this clearly destroys any hope of weak nor- 
malization. We expect to handle the necessary quotienting-out of terms at irrelevant conses in a different 

way. 


5 Pattern substitutions 

We define a judgment .spat”*'. where s is a substitution, n a natural number, and I a list of natural 
numbers. Its intended meaning is that. « is a pattern substitution using deBrmjn indices from I which aie 

no greater than n. 

t" pat"-' 

.spat "- 7 m<n,m#I .spat "- 7 

m r X pat rl - , ' m a 1 * pat ' 1 - 7 

From this we can define pattern terms via a judgment. «pat n ^ 7 . defined by the rules 

,s pat ' 1 - 7 
X[*] pat ' 1 - 7 

a pat "- 7 m < n, m & I « pat ' 1 - 7 

a o r m pat"- 7,m " o’ fcpat n - 7 
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Definition 1. A An' -trim is a An' -pattern if all of its subterms of the form a = (A'[.s] b } •••/;„) are such 
that a pat"-' for some n.I. A pattern substitution is a \a' -substitution all of whose A er' -normal forms s 
are such that s pat "- 1 for some n. I . 

Note that, in the absence of any confluence result we hedge our definition of of pattern substitutions bv 
referring to all normal forms rather than the normal form of the substitution s. Since we do not have 
substitution variables, wo hope that, in fact, the normal forms of substitutions are well-behaved, and this 
inelegance can bo removed. 

The proof in [3] that pattern spines have one-sided inverses is constructive, and so can be described 
algorithmically. We first give a direct description, and then sketch how to modify the algorithm. By unrolling 
the induction definition, a pattern substitution £ is of the form 


Put 


fli - /M -a n t m 

£ - In r b 2 - r ■ • ■ b m r r 


where 

b t = / j If = r A (ij = i; 

l a frc?sh variable A r otherwise. 

Observe that 

*<>«-►* oi [«) -" 2 ■ • • a„[ej r 

For any i, if //, is r, then by definition of { and pattern substitutions we have Oj[^] -»* i. Otherwise, ftj is i, 
and we have some term a, [£] occurring at an irrelevant position in the substitution f . The intended meaning 
of irrelevance is that this is just as good as any other term at the same type, in particular the deBruijn index 
i. Therefore, in a certain sense (and determining the right w T ay to formalize this is the subject of our current 
effort ) w : e have 

£o£ss 1 ■>“ 2 112 ■■•n "" f* ->* id 

To modify the algorithm, we add modality annotations to the existing rules in a straightforward way. 
and add two rules, 


NDI «[«•*£] 1 = (n[£] *)[t] 

udi ro( B .'o-' =(t m oc>t 

which cause irrelevant conses to act as if they were deBruijn indices that ‘never occur,’ in the sense that they 
never match other indices during application of an inverse substitution to a term (NDI is like ND/ in [3]) 
and they never occur in the range of t" 1 during composition of a substitution with an inverse substitution 
(UDI is like UDI). 


6 Future Work 

Computing the inverse is not the only operation on substitutions involved in the unification algorithm of 
[3]. We must also extend the definition of intersection to transform equations of the form A’ [£] = A [(,]. 
and the pruning substitution £|C to correctly handle flexible occurrences of metavariables. Moreover it may 
be that the notion of flexible occurrence can be extended to include occurrences of metavariables anywhere 
under irrelevant application while maintaining the correctness of the overall algorithm. We intend to work 
out the appropriate extensions of these concepts towards a complete unification algorithm for higher-order 
patterns in the extended theory, and answer the basic questions of normalization and confluence mentioned 
above. 
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Abstract. We present a verification of the Rijndael symmetric block cipher in the HOL-4 theorem 
prover. In general, the proofs were easy: they proceeded largely by symbolic execution along with a 
lew applications of algebraic rewrite rules, which were also easy to prove. However, the proofs depend 
on tight control of symbolic execution; otherwise, the problem size became too large for an interactive 
system. An important aspect of the formalization was to phrase Rijndael as a functional program. 


1 Introduction 

Rijndael [1,2] is a collection of algorithms that encrypt and decrypt data. It recently won the AES (Ad- 
vanced Encryption Standard) competition to find a successor to DES. It was designed to be suitable for 
implementation in software and hardware (from smartcards to full custom VLSI). 

One of the attractions of verifying the- functional correctness of such a system is the simplicity of its 
specification: 


VA :ey. decrypt key o encrypt key = I 

Of course, the essent ial further requirement of a cipher is that it be hard to break: decryption of encrypted 
data should be infeasible in the absence of the key used to encrypt. Our work does not address this problem 
which appears far more difficult to settle. The usual methodology seems to bo one of falsification: proposed 

ripheis are subjected to a variety of attacks: if none work, the cipher is deemed “secure”, at least for the 
time being. 

The two specification documents for Rijndael, one by its authors Rijmen and Daemen, and one from the 
AES organizers, are admirably done. Each step in the algorithm is explained carefully and there are useful 
glossaries aimed at avoiding any possible confusion. As well, there are appendices giving exact values for 
the intermediate values of the state after each of the important steps in a sample computation. However, 
for verification purposes, much of the specification has an unfortunate emphasis on arrays and updates on 
them. We therefore translated Rijndael into a purely functional program. 


2 Technical Preliminaries 

Many of the operations applied in Rijndael are operations involving the Galois field GF(2 8 ). This has a 
carrier set of 2o6 items, which is the number of elements enumerated by 8 bits. The byte bn is 

considered as a polynomial with coefficients in {0. 1}: 

b-x" 1 + &gx 6 + 65 x” + 6.1 x* 4- 63X 3 + b 2X 2 + b\x + bo 

Polynomial addition is bitwise exclusive-or, and so is subtraction. Multiplication of polynomials is harder, 
since we need to be closed under the operation. Thus multiplication is performed modulo an irreducible 
polynomial of degree 8; the chosen one for Rijndael is 

m(x) = x 8 + x 4 + x 3 + x + 1 

Written in hexadecimal, this is 11B. Naively done, modular multiplication of polynomials is slow (mul- 
tiplying through, then running a division algorithm) but it turns out that the full operation isn’t needed: 
instead, multiplication by a constant suffices. In order to multiply a polynomial b(x) by x, i.e... by hex 02. 
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W( Y rall [ ( »ft shift (<^C) followed by a conditional xor with 11B (which truncates to IB). This is the xtime 
operation: 1 

xtime b = (b <$C 1) xor (if b < 80 then 0 else IB) 

With this primitive 1 we can multiply a polynomial by any constant: the operation will be written as an 
infix • . Multiplication with higher powers of x can be achieved by iterating xtime and intermediate results 
can be added with xor: for example, multiplying 57 by 13 yields 

57 • 13 = 57 • (01 xor 02 xor 10) 

= 57 xor xtime(57) xor xtime(xtime(xtime(xtime(57)))) 

= 57 xor AE xor 07 
= FE 

There is also another notion of multiplication involved in Rijndael: one whore the polynomials have 
coefficients in GF(2 8 ), i.e., art 1 bytes. However, that notion serves mainly at the specification level for the 
algorithm and does not manifest itself in the code. Similarly, since wo are dealing with a field, there are also 
multiplicative inverse operations, but t hey are also not explicit in the code of the algorithm and so will not 
be discussed. 

3 Rijndael as a functional program 

We will present Rijndael as a program in SML. Translation to other functional programming languages 
should be easy. Since the algorithm deals extensively with bits and bytes, it is helpful if the host, programming 
language supports operations on these types. The SML library provides a structure Word8 implementing 
bytes (the type word8). Literals for bytes may be written in hexadecimal in the format Owx/ij/o. Exclusive*- 
or is provided by xorb. Rijndael is defined for three keylengt.hs: 128, 192, and 256 bits. Our verification is 
for a keylength of 128. 


3.1 The state 

The algorithm operates by repeatedly transforming a state of 16 8-bit bytes. In the original specifications, 
the state is represented as a 4x4 array. The algorithms access the state by byte, by row. and by column. 
Instead of an array, we represent a state by a 16-tuple of bytes. 

type state = vord8 * word8 * word8 * word8 * 

vord8 * word8 * word8 * word8 * 

word8 * vord8 * word8 * word8 * 

word8 * word8 * vord8 * word8 

The plaintext input is moved into the state by proceeding from left to 

right through the input and placing the bytes into ‘columns’. The inverse operation is used in decryption. 

fun to.state (bO ,bl ,b2 ,b3 ,b4 ,b5 ,b6 ,b7 ,b8 ,b9 ,bl0 ,bll ,bl2 ,bl3,bl4 ,bl5) 

(bO ,b4 ,b8 ,bl2 , 
bl.bS.bQ.blS, 
b2,b6,bl0,bl4, 
b3,b7,bll,bl5) 

fun from.state (bO ,b4 ,b8 ,bl2 , 
bl ,b5 ,b9 ,bl3, 
b2,b6,bl0,bl4, 

b3 ,b7 ,bll ,bl5) = (bO ,bl ,b2 ,b3 ,b4 ,b5 ,b6 ,b7 ,b8 , 
b9,bl0,bll,bl2,bl3,bl4,bl5) 

These functions show how pattern matching on tuples is used throughout instead of array indexing. 

1 Note that the < in this definition is a comparison on bvtes, and the literals 80, 0, and IB are hexadecimal. 

2 All literals are hexadecimal 



130 


Konrad Slind 


3.2 Rounds 

The main steps of the algorithm are orchestrated by the round computation. We have phrased this and its 
inverse as recursive functions. 

fun Round 0 [key] state = AddRoundKey key (ShiftRows (SubBytes state)) 

| Round n (key:: keys) state = 

Round (n-1) keys 
(AddRoundKey key 

(MixColumns (ShiftRows (SubBytes state)))) 

I Round _ = raise Fail "Round: bug"; 

fun InvRound 0 [key] state = AddRoundKey key 

(InvSubBytes (InvShiftRows state) ) 

I InvRound n (key: :keys) state = 

InvRound (n-1) keys 
(InvMixColumns 

(AddRoundKey key 

(InvSubBytes (InvShiftRows state)))) 

I InvRound = raise Fail "InvRound: bug"; 

In a round, the main operations on the state are to perform byte substitution using so called sboxe. .s, to 
shift the rows of the state, and to mix the columns of the state. We will discuss these in turn. 


Sboxes The Sbox is a permutation on bytes designed to be resistant to linear arid differential cryptanalysis. 
We create the function and its inverse InvSbox from vectors of bytes. 

val Sbox = curry Vector. sub (Vector . fromList 

[0wx63 , 0wx7c ,0wx77 , 0vx7b , Owxf 2 , 0wx6b , 0wx6f , 0wxc5 ,0wx30 ,0wx01 ,0wx67 ,0wx2b , Owxfe ,0wxd7 .Owxab, 0wx76 , 

0wxca,0wx82 ,0wxc9 ,0wx7d , Owxf a . 0wx59 , 0wx47 , Owxf 0 , Owxad , 0wxd4 ,0vxa2 ,0wxaf ,0wx9c ,0wxa4 ,0wx72 , OwxcO , 

0wxb7 ,0wxf d ,Owx93 ,0wx26 ,Ovx36 , 0wx3f , Owxf 7 , Owxcc ,0wx34 , OwxaB ,0wxe5,0vxf 1 ,0wx71 ,0wxd8,0wx31 , Owx 15 , 

0wx04 ,0wxc7 ,0wx23 ,0wxc3 ,0wxl8 , 0wx96 , OwxOB ,0wx9a,0wx07 , 0wxl2 ,0wx80,0vxe2 ,0wxeb ,0ux27,0wxb2 , 0wx75 , 

0wx09 , 0wx83 ,0wx2c ,0wxla ,0wxlb , 0wx6e , 0wx5a ,0wxa0 , 0wx52 , 0wx3b ,0wxd6, 0wxb3 ,0wx29 ,0wxe3 ,0wx2f ,0wx84 , 

0vx53 , Owxdl .OwxOO , Owxed ,0wx20 , Owxf c , Owxbl , OvxBb , 0wx6a , Owxcb ,0wxbe , 0wx39 ,0wx4a,0wx4c ,0wx58 ,0wxcf , 

OwxdO ,0wxef , Owxaa.Owxf b ,0wx43 ,0wx4d ,Ovx33 ,0vx85 ,Ovx45 , Owxf 9 ,0wx02, 0wx7f ,0wx50 ,0wx3c ,0wx9f ,0wxa8 , 

0wx51 ,0wxa3 , 0wx40,0wx8f ,0wx92 ,0wx9d ,Owx38 ,0wxf 5 .Owxbc ,0wxb6 , 0wxda,0wx21 ,0wxl0 ,0wxf f , Owxf 3 ,0wxd2 , 

Owxcd.OwxOc , Owx 13, Owxee , OwxBf ,0vx97 ,0wx44 ,0wxl7 ,0wxc4 ,0wxa7 , 0wx7e ,0wx3d ,0wx64 ,0wx5d,0wxl9 ,0wx73 , 

0wx60,0wx81 , 0wx4f , Owxdc , Owx 22 ,0wx2a ,0wx90 ,0wx88 ,0vx46 , Owxee , 0wxb8,0wxl4,0wxde,0wx5e ,0wx0b f 0wxdb, 

OwxeO , 0wx32 ,0wx3a , OwxOa, 0wx49 ,0wx06 ,0wx24 , 0wx5c ,0wxc2 ,0wxd3 ,0wxac , 0wx62 ,0wx91 ,0wx95 , 0wxe4 , 0wx79 , 

0wxe7 , 0wxc8 ,0wx37 ,0wx6d, 0wx8d ,0wxd5 , 0wx4e , 0wxa9 ,0wx6c , 0wx56 , Owxf 4 , 0wxea,0wx65 ,0wx7a ,0wxae , Qwx08 , 

Owxba , 0wx78 , 0wx25 ,0wx2e , Owxlc ,0wxa6 ,0wxb4 , 0wxc6,0wxe8 , Owxdd, 0wx74 ,0wxlf ,0wx4b,0wxbd , 0wx8b ,0vx8a , 

0wx70 , 0wx3e , OwxbB ,0wx66 , 0wx48 , 0wx03 , Owxf 6 , OwxOe ,0wx61 , 0wx35 , 0wxS7 ,0wxb9 ,0wx86 ,0wxcl , 0wxld,0wx9e , 

Owxel , Owxf 8 , 0wx98 , Owxll ,0wx69 , 0wxd9 , 0wx8e , 0wx94 ,0wx9b, Owxle , 0wx87 ,0wxe9 f Owxce ,0wxSS , 0wx28 ,0wxdf , 

0wx8c ,0wxal , Qwx89 , OwxOd, Owxbf , OwxeG , 0wx42 ,0wx68 , 0wx41 ,0wx99 ,0wx2d,0wx0f , OwxbO ,0wxB4 , 0wxbb,0wxl6] ) 
o Word8.toInt 

val InvSbox = curry Vector. sub (Vector . fromList 

[0wxB2 , 0wx09 , 0wx6a , OwxdB , 0wx30 , 0wx36 , OwxaB , 0wx38 , Owxbf > 0wx40 , 0wxa3 , 0wx9e , 0wx8 1 , Owxf 3 , 0wxd7 , Owxf b , 

0wx7c ,0wxe3 , 0wx39 , 0wx82 ,0wx9b , 0wx2f , Owxff p 0wx87 , 0wx34 , 0wx8e , 0wx43 ,0wx44 ,0wxc4 ,0wxde ,0wxe9, Owxcb , 

0wxB4 ,0wx7b , 0wx94 ,Owx32 , 0wxa6 , 0wxc2 , 0wx23 ,0wx3d, Owxee ,0wx4c ,0wx95 ,0wx0b,0wx42 ,0wxf a,0wxc3, 0wx4e , 

0wx08 , 0wx2e , Owxal , 0wx66 , 0wx28 , 0wxd9 , 0wx24 , 0wxb2 , 0wx76 , OwxBb , 0wxa2 , 0wx49 , 0wx6d , 0wx8b , Owxdl , 0wx25 , 

0wx72 , Owxf 8 ,0wxf 6 ,0wx64 , 0wx86 ,Owx68 ,Owx98 , Owx 16 ,0wxd4 ,0wxa4 ,0wx5c , Owxcc , OwxBd , 0wx65, 0wxb6,0wx92, 

0wx6c , 0wx70 , 0wx48 , OwxBO , Owxf d , Owxed , Owxb9 , Owxda , 0wx5e , Owxl B , 0wx46 , Owx57 , Owxa7 , 0wx8d , 0wx9d , 0wx84 , 

0wx90 , 0wxd8 , Owxab , OwxOO , 0wx8c , Owxbc , Owxd3 , OwxOa , Owxf 7 , 0wxe4 , 0wxB8 , 0wx05 , 0wxb8 , 0wxb3 , 0wx4S , 0wx06 , 

OwxdO ,0wx2c , Owxle ,0wx8f , Owxca ,0wx3f , OwxOf ,0wx02 , Owxel ,0wxaf ,Owxbd, 0wx03 ,0wx01 , Owx 13 ,0wx8a,0wx6b , 

0wx3a,0wx91 , Owxll ,0wx41 ,0wx4f ,0wx67 ,0wxdc ,Owxea , 0wx97 , Owxf 2, Owxcf, Owxce, Owxf 0,0wxb4,0wxe6,0wx73 , 

0wx96 ,0wxac ,Owx74 ,0wx22 ,0wxe7 , Owxad , 0wx3B ,Owx8B ,Owxe2 , Owxf 9 ,0wx37 , 0wxe8 , Owxlc ,0wx75 , Owxdf ,0wx6e , 

0wx47 , Owxf 1 , Owx la , Owx 71 , Owx id ,0wx29 .OwxcB ,0wx89 ,0wx6f ,0wxb7 , 0wx62, OwxOe ,0wxaa ,0wxl8 , Owxbe , Owx lb , 

Owxf c ,0wx66 ,0wx3e ,0wx4b ,Owxc 6 ,Owxd2 ,Owx79 ,0wx20 ,0wx9a ,Owxdb, OwxcO, Owxf e,0wx78, Owxed, OwxBa, Owxf 4 , 

Owx If , Owxdd, 0wxa8,0wx33 ,Owx88 ,0wx07 ,Owxc7 ,0wx31 , Owxbl , Owx 12 , OwxlO,OwxS9,Owx27 ,0wx80 , Owxee , OwxSf , 

0wx60 ,OwxSl , 0wx7f , 0wxa9 , Owx 19 .OwxbB ,0wx4a, OwxOd ,Owx2d , OwxeB , 0wx7a, 0wx9f ,0wx93 ,0wxc9 , 0wx9c .Owxef , 

OwxaO , OwxeO, 0wx3b,0wx4d , Owxae ,0wx2a ,0wxf B , OwxbO ,0wxc8 ,0wxeb ,0wxbb, 0wx3c , 0wx83 ,OwxB3 , 0wx99 ,Owx61 , 

Owx 17 , 0wx2b ,0wx04 ,0wx7e , Owxba, 0wx7 7 ,0wxd6, 0wx26 , Owxel , 0wx69 , Owx 14 ,Owx63 , 0wx5B , 0wx21 , OwxOe ,Owx7d] ) 
o Word8.toInt 


3.3 Byte Substitution 

A byte substitution step applies an sbox to each element in the state: we phrase this as a higher-order 
function for re-use: 
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fun genSubBytes S (bO ,bl ,b2 ,b3 ,b4 , b5 ,b6 ,b7 ,b8 ,b9 ,blO ,bll ,bl2 .bl3.bl4 ,bl5) 

(S bO, S bl, S b2, S b3. S b4, S b5, S b6, S b7, 

S b8, S b9, S blO, S bll, S bl2, S bl3, S bl4, S bl5) 

val SubBytes = genSubBytes Sbox 

val InvSubBytes = genSubBytes InvSbox 


3.4 Shift Rows 


In a row shift step, t he first row is not altered, 
by 2, and the fourth row is left -shifted by 3. 


the second row is left-shifted by one. the third row is left -shifted 


fun ShiftRous (bOO.bOl ,b02,b03, 
blO ,bll ,bl2 ,bl3 , 
b20 ,b21 ,b22 ,b23 , 
b30 ,b31 ,b32 ,b33) 

(bOO.bOl, b02,b03, 
bll ,bl2 , bl3 ,blO , 
b22 ,b23 ,b20 ,b21 , 
b33 ,b30 ,b31 ,b32) 

fun InvShiftRows (bOO.bOl ,b02 ,b03, 
bll ,bl2 ,bl3 ,blO , 
b22 ,b23 ,b20 ,b21 , 
b33 ,b30 ,b31 ,b32) 

(bOO.bOl ,b02 ,b03 , 
blO ,bll ,bl2 ,bl3 , 
b20 ,b21 ,b22 ,b23 , 
b30,b31 ,b32,b33) 


3.5 Mix Columns 

The mixing of columns is relatively complex in its operation. Each column in the state is treated as a four- 
term polynomial over GF(2 8 ) and multiplied modulo x* + 1 with a fixed polynomial. A higher-order function 
captures the general pattern for the forward and reverse operations: 


fun genMix Columns MC (bOO , bOl ,b02 , b03 , 
blO ,bll ,bl2 ,bl3 , 
b20 ,b21 ,b22 ,b23 , 
b30,b31 ,b32,b33) 


= let val 

o 

o 

blO J 

b20 * , 

b30 ’ ) = MC 

val 

(bOl ’ , 

bir 

b21 ’ f 

b31 ’ ) = MC 

val 

(b02 ’ , 

b!2* , 

, b22 ’ , 

b32 ’ ) = MC 

val 

(b03 ’ , 

bl3 J , 

i b23 * , 

b33 ’ ) = MC 


(bOO ,blO ,b20 ,b30) 
(bOl ,bll ,b21 ,b31) 
(b02 , bl2 , b22 , b32) 
(b03.bl3.b23.b33) 


in 

(bOO’ . bOl ’ , b02 ’ , b03’ , 
blO’ , bll’ , bl2 ’ , bl3’ , 
b20’ , b21 ’ , b22 ’ , b23’ , 
b30’ , b31 ’ , b32 ’ , b33’) 
end 


val MixColumns = genMixColumns MultCol 

val InvMixColumns = genMixColumns InvMultCol 
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In the forward direction, the fixed polynomial is a(x) = 03x ;! + Olx 2 + Ol.r + 02. After some massaging, we 
arrive at the following transformation on the column: 

fun MultCol (a,b,c,d) = 

((0wx02 ** a) xorb (0wx03 ** b) xorb c xorb d, 

a xorb (0wx02 ** b) xorb (0wx03 ** c) xorb d, 

a xorb b xorb (0wx02 ** c) xorb (0wx03 ** d) , 

(0wx03 ** a) xorb b xorb c xorb (0wx02 ** d) ) 

The inverse operation is harder, in the sense that larger coefficients are used: the fixed polynomial is a~ 1 (x) = 
0B.r ! + ODj - + 09j’ + 0E. The column transformation is: 

fun InvMultCol (a,b,c,d) = 

( (OwxOe ** a) xorb (OvxOb ** b) xorb (OwxOd ** c) xorb (0wx09 ** d) , 

(0wx09 ** a) xorb (OwxOe ** b) xorb (OwxOb ** c) xorb (OwxOd +* d) , 

(OwxOd ** a) xorb (0wx09 ** b) xorb (OwxOe ** c) xorb (OwxOb ** d) , 

(OwxOb ** a) xorb (OwxOd ** b) xorb (0wx09 ** c) xorb (OwxOe ** d) ) 

These operations are defined in terms of multiplication by a constant, represented by the infix ** symbol: 

fun xtirae b * (b « Owxl) xorb (if b < 0wx80 then OwxO else OwxlB) 

fun (OwxO ** v) = OwxO 

I (c ** v) = if andb(c ,0wx01) = OwxOl 

then v xorb ((c >> Owxl) ** (xtime v)) 
else ((c >> Owxl) +* (xtime v) ) 

There is also an exponentiation operation, used to generate the key schedule: 


fun exp (x,0) = OwxOl 

I exp (x,n) = x ** exp (x,n-l) 


4 Generating the key schedule 

An important part of Rijndael is the calculation of the key schedule (a list of round keys ) from the original 
key, as a preliminary step to the round computations. In each round, a new round key is added to the state 
pointwise with AddRoundKey: 

fun AddRoundKey 

(kO,kl ,k2,k3,k4,k5 t k6,k7,k8,k9,kl0,kll ,kl2,kl3,kl4,kl5) 

(bO.bl »b2, b3,b4,b5,b6,b7,b8,b9 1 bl0 > bll ,bl2,bl3,bl4 f bl5) 

(bO xorb kO, bl xorb kl, b2 xorb k2, b3 xorb k3, 

b4 xorb k4, b5 xorb k5, b6 xorb k6, b3 xorb k3, 

b8 xorb k8, b9 xorb k9, blO xorb klO, bll xorb kll, 

bl2 xorb kl2, bl3 xorb kl3, bl4 xorb kl4, bl5 xorb kl5) 

The specification calls for the key schedule to be generated by operations on 32-bit words. In our version 
of ML (Moscow ML), only 31-bit words were available, so we rephrased the algorithm over quadruples of 
bytes. We will pass over the code in silence, since it is somewhat involved and the details are not important 
for the correctness proof. 

local open Int nonfix o 

fun SubWord (bO ,bl ,b2,b3) = (Sbox bO, Sbox bl, Sbox b2, Sbox b3) 
fun Rot Word (bO ,bl , b2 ,b3) = (bl ,b2 ,b3 , bO) 

fun Rcon i = (exp(0wx02, i-1) , OwxOO , OwxOO , OwxOO) : word8x4 
fun unpack [] A = A 

I unpack ((a,b,c,d) : : (e,f ,g,h) : : (i, j ,k,l) : : (m,n,o,p) : :rst) A 
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= unpack rst ((m,i,e,a,n t j t f,b,o t k,g,c,p,l,h,d)::A) 

| unpack otherwise . = raise Fail "generate.keysched (unpack) 


fun mk_keysched top (bO ,bl ,b2 ,b3 ,b4 ,b5 ,b6 ,b7,b8 ,b9 ,blO , bll ,bl2,bl3,bl4,bl5) = 
let fun expand n (sched as (h: last :: _)) 
if n>top then unpack sched [] 
else let val h' = if n mod 4 <> 0 then h . 

else SubWord (RotWord h) xor4 Rcon(n div 41 

in expand (n+1) ( (h * xor4 last) :: sched) 
end 


expand 4 [(bl2.bl3,bl4.bl5) . (b8,b9,bl0.bll) , (b4,b5,b6,b7) , (bO.bl ,b2,b3)] 


end 

end 


Fiuallv ,hn top-lav, -I tu.irtiow.lity «. I* ,hl * lakos " k< 7 “? ' ‘ 

koVM'hodulo before building ncryp.ion and decryption funetioiia. The enerypt.on f„ne„o„ the ht, 

schedule and the decryption function uses the inverse of the key schedule. 


fun preCrypt key = 
let open Int 

val Nr = 10 

val keysched = mk.keysched (BlockSize * (Nr+1) -1) key 

val (keyO : :keys) = keysched 

val (ikeyO : : ikeys) = List. rev keysched 

(from_state o Round (Mr-1) keys o AddRoundKey keyO o to.state, 
from.state o InvRound (Mr-1) ikeys o AddRoundKey ikeyO o to_state) 

end 


5 The verification of Rijndael 

Rijndael is directly encoded in HOL with only a few alterations from the SML program. 


5.1 Bytes 

\n interesting modelling question is how best to represent bytes. In SML, bytes (words) are an abstract type 
tnnimoratval by 2 5 6 JH HOT dona no, however have by.ee bull. ,n. 

choices: hvtes mav be represented by an enumerated type, or by the numbers up to 2o6. or by 8 tuples 
truth values. Although it is inefficient in a sense, we chose the latter representation. 

To start,, we define a few byte constants: 


ZERO = 
ONE = 
TWO 
THREE : 
NINE : 
ONE.B 
EIGHTY 
B 
D 
E 


(F, F, F, F, 
(F, F, F. F, 
(F, F, F. F, 
(F, F, F, F 
(F, F F, F, 
(F, F, F, T, 
(T, F, F, F, 
( F, F, F, F, 
(F, F, F, F, 
(FFF.F. 


F, F, F. F) 
F. F. F, T ) 
F. F. T. F) 
F, F, T.T) 
T. F, F.T) 
F, F, T.T) 
F. F F. F) 
T. F, T, T) 
T.T, F.T) 
T, T. T. F) 


Infix operators for ‘exclusive-or 
bvtes: 


on 


bits and bytes are defined, along with an infix ‘and’ 


operation on 
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x xor y = i(.r = i/) 


/ (a. 6. r, d.e,f,g,h) 

XOR 

\ («i, 61. r, , d, .<•!,/], 51, /j[) 

/ (a,b,r,d,e,f,g,h) 

AND 

\ («l ? &1 • f'l , dj , f'i , /( , ryj , /), ) 


a xor a, , b xor h \ , r xor c, , d xor dj , 
r xor f'i , / xor f x , g xor g t , h xor h\ 



a A a i , h A &i , r A e, , d A di , 
(, Af] , / A fi.g A Hi , // A /( ( 


) 


A few trivial algebraic theorems then follow: ZERO is the identity for XOR, commutativity, and asso- 
nativity. 

t- x XOR ZERO = X 
b (.r XOR y) = (y XOR x) 

b (x XOR y) XOR z = x XOR (y XOR z) 


5.2 The state 

The functions to_state and from_state for mapping into and out of a state are exactly the same? as the ML 
definitions. That they are inverses of each other is trivial: 


I- V.s*. from_state(tojstate .s) = s 
b Vs. to_state(from_state s) = s 


5.3 Applying an sbox to the state 

The functions SubBytes and InvSubBytes for applying an sbox to a state are exactly the same as the 
ML definitions. The sboxes are each defined by a 256-way pattern match. The inversion theorem for these 
functions is a consequence of the inversion theorem for sboxes, which is proved by analyzing all 256 cases 
and evaluating the sboxes. 

b InvSbox(Sbox w) = w 
b Vs. InvSubBytes (SubBytes s) = s 

5.4 Shifting rows 

The functions ShiftRows and InvShiftRows for shifting rows in a state are exactly the same as the ML 
definitions. The inversion theorem for these functions is trivial to prove. 

b V.s. InvShiftRows(ShiftRows ,s) — s 


5.5 Multiplication 

. The definitions of the multiplication functions largely follow the definitions. The xtime function is slightly 
different, owing to our representation: 


xtime (b 7 , b 6 ,b b ,b.t,b 3 , b 2 , 6] , b 0 ) = 

if b 7 then (6g, b ~'b 3 , — > b 2 , b \ , —< bo , T ) 
else (b 6 ,b b ,b 4 ,b.i,b 2 ,b u b 0 , F) 

The xtime function enjoys a distributive property: 


V« b. xtime(o XOR b) = (xtime a) XOR (xtime b) 
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Multiplication by a constant is a direct translation. 

b { . b 2 = if b\ = ZERO then ZERO else 
if {b } AND ONE) = ONE 

then b-> XOR ((RightShift ?>, ) • (xtime b>)) 
else (RightShift ) • (xtime b 2 ) 

Termination of the function is proved by regarding the first argument as a number. The • operation 
distributes over XOR: 

h Vx y z. x • (y XOR *) = (*• v) XOR (:r • z) 


5.6 Column mixing 

With column mixing, the proofs became larger. We need the inversion theorem 

h V.s : state. InvMixColumns(MixCohimns s) = s 

for the final proof, but naive cast, analyses became too large and we had to resort to much more basic steps. 
To see the problem let’s consider the action on a column (a.b.e.d). In the forward direction, we have 

a' = Fi(n.b.c,d ) 
b' = F>(a, b. c, d) 
c' = F 3 (a.b.c,d) 
d' = FAa.b.c.d) 


and in the reverse we build up 

a" — G\(a! ,b' ,c’ .d') 
b" = G 2 (a' ,b' ,c' ,d') 
c" = G-Aa'.b'.c'.d') 
d" = G\(a' ,b' .<■' ,d') 


and we wish to show that a — a" .b — b ,c 


c",d = d” . Consideration of a should illustrate our strategy. 


a' = (TWO • a) XOR (THREE • b) XOR c XOR d 
b' = a XOR (TWO • b) XOR (THREE • c) XOR d 
c' = a XOR b XOR (TWO • c) XOR (THREE • d) 
d' - (THREE • a) XOR b XOR c XOR (TWO • d) 


Thus 

a" = (E • «') XOR (B • b') XOR (D • c') XOR (NINE • d') 

- (E • ((TWO • a) XOR (THREE • 6) XOR c XOR d)) XOR 
(B • (a XOR (TWO • b) XOR (THREE • c) XOR d)) XOR 
(D • (a XOR b XOR (TWO • c) XOR (THREE • d))) XOR 
(NINE • ((THREE • a) XOR b XOR c XOR (TWO • d))) 


Bv use of associativity and commutativity of XOR and distribution of • over XOR. wo can separate 
the problems into subproblems involving only one variable, each of which are easy to solve by ease analysis 
on the 256 ways of forming a byte. 

= (E . (TWO . a) XOR E . « XOR D • « XOR NINE • (THREE • a)) 

XOR 

(E • (THREE • b) XOR E • (TWO • b) XOR D • b XOR NINE • b) 

XOR 

(E • c XOR E • (THREE • c) XOR D • (TWO • r) XOR NINE • r) 

XOR 

(E • d XOR E . d XOR D • (THREE . d) XOR NINE • (TWO • d)) 

= a XOR ZERO XOR ZERO XOR ZERO 


= a 
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5.7 Joe Hurd’s good suggestion 

The' computation of the key schedule is fairly complex. If we needed non-trivial properties of it in order 
to show correctness, significant extra work would be required. After listening to a preliminary presentation 
on this work. Joe Hurd suggested that it might suffice merely to treat the key schedule as an arbitrary 
list of keys. In fact, since the round computation consumes one key per round, it suffices to show that the 
key schedule is an arbitrary key list of length 11. With this fact, the final correctness proof had no more 
impediments. 

To prove this was, again, not simply a matter of symbolic* evaluation. First we proved an invariant on 
the key expansion routine. 

1- Vn. t . 

3 < n A n < 44 

3 h. expand (n + 1) (h :: t) = expand n t 

This leads directly to a theorem relating the first and last calls of the key expansion routine, 
b Va b r d. 

3/ii If 2 h.i h\ /i'5 /i(i hj hx hg h\o h u h \ 2 /*i 3 hu b 1 5 b ]G If 17 h\n If \9 h 20 
)l 2 [ h '22 If 23 If 24 ^25 ^26 h 27 ^28 /*29 ^30 />-31 ^32 />33 ^31 h 35 h\\ G }v\$ k$g h 4 g. 
expand 44 [/*4o; h^g\ h^x \ h^ 7 : h\w \ ft 3 5 ; ^34 i ft 33; ^32 : ft.31 ; // 30 ; ft 2 9; ft 2 8; 

^27? ^26? ^25 « /i24? ^23? ^22? ft*21 ? ^20? ft-lfli ft 18 1 ft]7? /? 1 6 1 ftif>; 

b i 4 ? If 1 3 ? If 1 2 • h 1 1 1 ft i o ; ^9 ; h% \ ft 7 ; h G ; ft r, ; ft 4 : /*» ; ft 2 ; ft 1 ; a : 6; c; r/] 

expand 4 [a; b: r; d] 

From this we quickly get that the length of the list returned by mk_keysched is 11. 
b Vkey. 3h\ hzhzhihshfihrhshghiohii . 

ink_keysched key = [h^ ; ft 2 ; ft:*; h 4 ;hz\ ft 6 ; ft 7 ; ft 8 ; hg\ ft 10 ; ft n ] 

This theorem can be immediately used to build a representation of the key schedule suitable for symbolic 
execution. 

5.8 Correctness 

The statement of correctness is 

Vkey plaintext. 

let ( encrypt , decrypt) — preCrypt key 
in 

decrypt(encrypt plaintext) = plaintext 

The definition of preCrypt is merely an organizational device aimed at making a neat statement of the 
final theorem. In the definition, the key schedule and its reverse are built from the key, and then the pair of 
functions ( encrypt , decrypt) is returned. The encryption function copies the input into the state, makes an 
initial scrambling step with the first key, and then makes 10 rounds of further scrambling before transferring 
the final state to the output. The proof shows that the decryption function basically reverses these steps. 

preCrypt key = 

let sched — mk_keysched key in 
let inched = REVERSE sched 
in 

((from_state o Round 9 (TL sched) 

o AddRoundKey (HD sched) oto_state), 

(from_state o InvRound 9 (TL isched) 

O AddRoundKey (HD isched) o to_state)) 
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The proof of correctness starts by expanding the definition of preCrypt. Then the lemma on the length of 
key schedules is used to replace the variables representing the key schedule and its reverst 1 by corresponding 
lists of eleven variables. Now the 11) rounds of encryption and the 10 rounds of decryption an' unwound, 
giving a large formula. The proof finishes by rewriting with the inversion lemmas. 


5.9 An alternative decryptor 

Daemon and Rijmen present an alternative implementation of the inverse round computation: 

fun EqlnvRound 0 [key] state = AddRoundKey key 

(InvShif tRows 

(InvSubBytes state)) 

| EqlnvRound n (key:: keys) state = 

EqlnvRound (n-1) keys 
(AddRoundKey key 
(InvMixColumns 
(InvShiftRows 

(InvSubBytes state)))) 

The alternative differs from the original in that the calls to InvShiftRow and InvSubBytes are swapped, 
as are the calls to AddRoundKey and InvMixColumns. 

InvRound with a key schedule ks is equivalent to EqlnvRound with InvMixColumn mapped over ks 
(except for the first and last elements). The mapping operation over the key schedule is called InvMixify: 

InvMix [x] = [x] 

InvMix (h :: t) = InvMixColumns h :: InvMix t 
InvMixify ( h :: t) = h :: InvMix t 

In the alternative version of preCrypt, the forward computation is unchanged, and only the inverse 
rounds and their key schedule are altered: 

preCryptAlt key = 

let sched — mk_keysched key in 

let isched = InvMixify (REVERSE sched) 

in 

((from .state o Round 9 (TL sched) 

O AddRoundKey (HD sched) o to.state), 

(from .state o EqlnvRound 9 (TL isched) 

o AddRoundKey (HD isched) o to_state)) 


With the lemmas 

b V.s. InvShiftRows (InvSubBytes s) = InvSubBytes (InvShiftRows ,s) 
h V.s k . InvMixColumns (AddRoundKey ,s k) 

AddRoundKey (InvMixColumns ,s) (InvMixColumns k) 


it is easy to prove 


h preCryptAlt = preCrypt. 


6 Conclusions 

The verification of Rijndael was relatively easy, which is good. One aspect of the problem was learning by 
trial and error which definitions led to exponential symbolic evaluations. Lemmas about the generation of 
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the key schedule and the mixing of columns were the main examples and required the majority of the effort. 
Symbolic execution allowed the avoidance of any intimidating abstract algebra. Rijndael, when rendered as 
a functional program, is also quite simple* and could be taught to undergraduates with little difficulty. Thus, 
it may be useful as a pedagogical example of verification technology. 

There are several interesting avenues to explore: 

— We anticipate that proofs for the other key lengths will be straightforward. 

— The code we have proved correct, encrypts and decrypts only a single block. So-called modes of opera- 
tion specify various ways to encrypt arbitrary streams of data. Extending our work to these should be 
straightforward. 

- We would like to investigate the generation of hardware, e.g ., gate arrays, directly from the HOL for- 
mulation. There has already been much work on putting Rijndael into hardware, but the provision of a 
path from higher-order logic to hardware seems appealing. 

- Finally, encryption is one of a family of similar operations characterized by invertibility ; for example, 
compression/decoinpression and encoding/decoding. It would be interesting to see if commonalities can 
be found in the correctness proofs of these algorithms. 
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Abstract. The K combinator provides a semantic-ally transparent tagging mechanism which is useful 
in various aspects of mechanizing higher order logic. Our examples include: numerals, normalization 
procedures, named hypotheses in goal-directed proof, and rewriting directives. 


1 Introduction 

Combinatory logic* is based upon the two combinators S and K: 

S / g x = / x (fl x) 

K x y = x 

As is well-known, these two definitions are equivalent in power to Turing machines and the untyped 
lambda calculus. Combinators have also been used as the basis of abstract, machines that implement func- 
tional programming languages, like Miranda [9]. General purpose computing machines based on combinators 
have even been realized as hardware. It is amazing that such a simple syntax is so powerful. 

Our purpose is to expound another use of combinators, the K combinator in particular. On examination 
of S and K, one can (fancifully perhaps) see a split between S, which takes care of the functions, and K, 
which takes care of the data. Our interest is in representing particular external data in higher order logic. 
We will use instances of the K combinator in HOL as a tagging mechanism. The approach depends on the 
fact that an application 

K t, h 

has both the same type and the same meaning as t\ . We can put whatever well-formed term we wish in 
< 2 . Thus if we want to somehow associate t, 2 with 1. 1 , we can transparently replace f, by K f, t 2 . One use 
of this flexibility is to have t> be data that can be interpreted by external tools. Our examples show that 
the external tools can range* from object-language syntax faculties like parsers and pretty-printers to proof 
support systems, to automated reasoners. 

As might, be expected, the K combinator is also used in functional programming. For example, in ML, 
with its left-to- right call-by-value evaluation strategy, the infix function before defined by 

fun (;r before y) — x 

has the following behaviour: an expression M before N is evaluated by evaluating M. then N, and then 
the* value of M is returned. Typically, evaluating N results in a side-effect (otherwise the use of before is 
pointless). 

From our viewpoint , K is far more useful in higher order logic than in a programming language because one 
can both create and eliminate applications of K in logic, while only eliminat ion is possible in a programming 
language. 

In the following, we shall use some tags that are instances of the I combinator. This doesn’t detract from 
our message, as we are thinking (not in any formal way) of K as a family of combinators: 

Kq X — X 

Kj x x\ = x 
K-2 X Xi X2 = X 
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Each K ?} has tvjx? isomorphic to a — > fi u — > a. Only the first two members of this family arc used in our 
examples. 


1.1 Related Work 

Kalvala has studied the application and implementation of tags [7]. The basic difference between her approach 
and ours is that she changes the underlying term structure to insert tags, while our tags arise from definitions 
and do not therefore require any changes to the kernel of the logic, Howe uses a tagging mechanism to attach 
types to the untyped terms of the Nuprl logic in [5]. Hut ter [G] provides a tour de force of annotation 
uses, showing how they can be used to support such disparate applications as first order theorem proving 
heuristics (e.g. basic ordered paramodulation), window inference, rippling, and analogical reasoning. Like 
Kalvala, Hotter \s approach requires altering the basic term structure. 

2 Numerals 

Our implementation of numerals for the natural numbers is similar to Harrison’s in his HOL Light system. In 
contrast with earlier implementations of HOL, numerals arc no longer members of an infinite set of constants. 
Instead they are values, constructed using three constants: 0, NB1 and NB*2. The two NB constants are 
defined 


NBl(x) = 2x 4- 1 
NB2(x) = 2* + 2 


Thus the number five is NB1(NB2(0)). This scheme has the advantage of unique representations for all 
numbers. 

We use a K 0 comhinator, called NUMERAL, to tag all numerals explicitly at the outermost level. As 
Harrison notes in [4], this has the advantage that numerals are not sub-terms of other numerals. We have 
also found the tag idea useful in our implementation of arithmetic on these numerals. This implementation 
is based on Barras's implementation of “call- by- value” rewriting [1], to which we pass a variety of rewrite 
rules. 

We begin by allowing addition to happen under the NUMERAL tag: 

NUMERAL(x) + NUMERAL^) = NUMERALS + y) 

A naive implementation of addition could then use the following rules: 

0 + x = x 
x + 0 = x 

NBl(ar) + NB1 (y) = NB2{x + y) 

NBl(ar) + NB2 (y) = NBl(SUC(.r + y)) 

NB2(.r) + NBl(y) = NBl(SUC(x + y)) 

NB2(x) + NB2 (y) = NB2(SUC(.r + y)) 


Here the SUC (“successor”) constant is being used liked a carry flag, to ripple along the rest of the com- 
putation. Unfortunately, in the absence of rules to pre-empt it , rewriting using the equations above won’t 
emulate this rippling very well because all of the x + y terms on the RHSs will be evaluated before the carry 
flag is used. 

The first step of our solution is to not provide any rules for addition directly. Instead, all additions have 
to happen under a family of three P tags: P 0 , Pi , and P 2 , where P„(m) is defined to have the value rn + n 
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(naturally, wo won't l>o expanding P„ tonus using this definition). P ( > is thus another K (l tag. Pi corresponds 
to the use of SUC above. P_> is necessary because 

P, (NB2(x) + NB2(t/)) = (2x + 2) + (2 y + 2) + 1 
= 2(.r + y + 2) + 1 
= NBl(P 2 (x + y)) 

Luckily, there is no comparable need for a P ;! flag when adding numbers under Pj. We also change the rule 
for addition under NUMERAL to be 

NUMERALS) + NUMERAL^/) = NUMERAL(P„(x + //)) 

Next, we need rewrite rules to calculate the effect of P! and P> when applied to single arguments (the 
situation does not arise for Po): 

P,(0) = NB1(0) P •>(()) = NB2(0) 

Pi (NBl(x)) = NB2(.r) P 2 (NBl(x)) = NBl(P,(.r)) 

P 1 (NB2(x)) = NB1(P) (x)) P>(NB2(x)) = NB2(P,(x)) 

Finally, our set of equations for addition (omitting x + y clauses when a clause for y + x is already present) 
is then: 

P o (0 + x) = x 

P„(NBl(x) + NBl(y)) = NB2(P 0 (.r + y)) 

P„(NBl(x) + NB2(y)) = NBl(Pi(x + y)) 

P 0 (NB2(x) + NB2(y)) = NB2(P, (x + y)) 

P,(0 + x) = P.(x) 

P, (NBl(x) + NBl(y)) = NBl(P,(x + i /)) 

P 1 (NBl(x) + NB2(.y)) = NB2(P, (x + ?/)) 

P,(NB2(x) + NB2(y)) = NBl(P L .(x + y)) 

P 2 (() + x) = P 2 (x) 

P_>(NBl(x) + NBl(y)) = NB2(P ^x + y)) 

P 2 (NB1(x) + NB2(y)) = NBl(P 2 (x + y)) 

P 2 (NB2(x) + NB2(y)) = NB2(P,(x + y)) 

() ur p„ tags can be seen as a specialised use of rewriting control, which we explore further below in 
Section 7. 

3 Normalization 

We have also used tags to implement a simple near-linear method for selecting and moving sub-terms to 
either end of a chain of arguments to an associative and commutative operator. 

For example, when writing proof tools, it can be useful to have a particular conjunct at the front of the 
term, in a known position. If the input term is 

Pi A P-2 A . . . Q . . . A P„ 

and we wish to have Q at the front of the term, one approach to achieving this would be to prove the original 
term equal to a new one 


Q A (Pi A ... A P n ) 
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General tools for doing such reordering proofs will necessarily take at least ()(n log n) time however, and if the 
terms are very big this cost can he significant. Alternatively, one might write a bespoke ‘‘term-reorganiser*' 
that carefully descended the term and did exactly the right sequence of transpositions to bring Q to the 
front . 

With tags, we have another alternative again. Define a “marker" K 0 tag, and descend the term to wrap 
it around Q. Then use the following theorems and HOL's general rewriter to bring marker(Q) to the front: 

P A marker(Q) = marker(<y) A P 
P A (marker (Q) A R) = marker(Q) A (P A R) 

(marker(Q) A P) A R = marker(Q) A (P A R) 


The final stage of the operation is to remove the marker wrapper from Q. 

The use of the rewriter makes the implementation very simple, yet the efficiency will be close to linear 
(only a linear number of swaps will lx* made*, lmt the rewriter may do some unnecessary work traversing 
other parts of the term looking for rewrites). 


4 Constraint Tagging 


The second author’s implementation of Cooper’s algorithm in HOL creates formulas that include terms of 
the form 

n 

y P{n) 

for fixed n. Because n is fixed, such formulas could be expanded directly into n disjuncts, but it is more 
efficient to keep the disjuncts unexpanded so that later simplification can reduce the size of n. This would 
be the result of the so-called “(5-elim illation” stage of the procedure, which might also replace n with an 
expression pararneterised by variables that are in turn bound by other finite constraints. 

HOL doesn't have an explicit pararneterised disjunction operator, so we represent such formaulas with 

3i. 1 < i A i < n A P(i) 

For reasons of efficiency within the procedure, it is useful to be able to quickly locate the pair of constraints 
on variable i, and there is no guarantee that they will always be maintained at the front of the body of the 
quantification, as here. We wrap them inside a Ki tag, where the additional information is the variable i. 
This makes it easy to locate constraints over particular variables. The formula then becomes 

3 i. K(1 < i A i < n) i A P(i) 

5 Named hypotheses in proofs 

Declarative proof interfaces have been a subject of recent interest in the interactive theorem proving com- 
munity. In such a. system [12,3,8, 13, 10], proofs are not given as a sequence of commands that alter a proof 
state — a procedural proof ~ but as a sequence of high-level assertions that closely follow the outline provided 
by a rigorous informal proof. Declarative proof systems offer readability and consequent advantages such as 
learnability and maintainability. In these systems, however, the original procedural proof interface- -which 
is often appropriate in the heat of a proof is either unavailable, hidden, or deprecated. 

This motivates the study of how combinations of declarative and procedural proof may be achieved. 
In fact, Harrison’s work implemented declarative proof by procedural proof. However, he implemented a 
separate proof interface which one had to use to perform declarative proofs. In contrast, later work by 
Wiedijk [11] augmented the native procedural proof interface of HOL with declarative elements. One could 
mingle declarative steps with procedural steps, or indeed use only declarative steps. Importantly, only a single 
interface to proof was required. Unfortunately, Wiedijk’s implementation was mostly aimed at showing how 
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easy it is to build such an interface (it took about 40 lines of ML), and hasn't yet been developed into a 
user-friendlv interface. 

An iinportant aspect of declarative proof is the attaching of names to hypotheses. In contrast, an impor- 
tant aspect of procedural (tactic) proof in the HOL88/90/98/4 implementations of HOL is that hypotheses 
in a goal are not named: they are a set. (The pros and cons of this have been extensively discussed m the 
HOL user community.) Thus any attempt to implement declarative proof in these systems will have to solve 
the problem of how to name and use hypotheses without having to rebuild the entire infrastructure of tactic 

1 Tags can be used to implement named hypotheses. We simply define a version of K, as a logical constant 


Named (x : bool) (y : a) — x 


Then an assumption .4 can be named n by K-expanding it to Named .4 n. Once a few simple tactics are 
written to access hypotheses by name, named hypotheses can exist in full harmony with unnamed hypotheses. 
This gives us a clean basis upon which to try to build declarative proof interfaces that co-exist with the 


existing interfaces. . . . r . 

An interesting subtlety, perhaps specific to HOL, is how to use named assumptions in tactics. For instance, 

the first-order model-elimination tactic MESON-TAC has type thin list -4 tactic. It uses the supplied 
theorems to prove a goal. Suppose we wish to provide a function ASM of type string -4 thin for fetching a 
named assumption from the hypotheses of a goal and making it a theorem, by assuming it. Thus we would 
be able to apply, c.g ., MESON.TAC [ASH "foo"] in order to use an assumption labelled with foo to prove a 
goal. However, the expression ASM "foo" must evaluate to a theorem, and the type of ASM forbids ASM from 
accessing the goal! (Using top_goal won't work.) Devious hackery is required. We manage to wriggle free 
of the conundrum by having ASM return an instance of reflexivity F foo = foo. where foo is a variable. The 
preprocessing phase of MESON-TAC which does have access to the goal has been adjusted to find 
such trivial instances and turn them into accesses into the hypotheses of the goal. 


6 Other operations on hypotheses 

Two other applications of tagging support, the abbreviation of subterms and the hiding of hypotheses. 

1. In larger proofs, formulas with many repeated subterms can occur. To aid readability, abbreviation 
tactics have been written. Such a tactic will create a new assumption v = M where M is the term to 
abbreviate, and r is a variable acting as its abbreviation, and replace all occurrences of M bv v. However 
such abbreviations don't work well with other tactics. For example, rewriting with the assumptions will 
re-expand any occurrences of v in the goal. For this reason, abbreviation tactics add the hypothesis in the 
reversed form M = v. However, this refinement is defeated by cleverer tactics that attempt, to eliminate 
(by substituting throughout the goal) all equality hypotheses v = M or M = t\’ Such hypotheses often 
occur as the result of rewriting with injectivity theorems. 

The workaround is to introduce a K 0 tag 

Abbrev (x : bool) = J* 

and then an abbreviation v = M would be represented by the expansion Abbrev (r = M), and would 
bo resistant to elimination bv clever simplification tactics. 

2. Another problem with larger proofs is extraneous hypotheses that clutter up the assumptions. They 
make the full goal hard to read, slowing interactive proof development. One way to deal with this is 
to eliminate them explicitly via a weakening tactic, but sometimes that is overly prescriptive. Anothei 
approach that may be useful would be to to introduce a Kq tag 

Hidden (x : bool) = x 


and have the system prettyprinter omit assumptions of the form Hidden M. 

1 Note that the variable is restricted to occur on only one side of the equality, in order to preserve provability. 
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7 Rewriting directives 

A basic functionality for a rewriter is to take a list of rewrite rules and apply them exhaustively to a term. 
Many other styles of rewriting are usually also required in proof assistants (rewriting with/ without a back- 
ground set. rewriting with/without the current assumptions, conditional rewriting, higher-order rewriting. 
etc), which leads to a large number of very closely related rewriting entrypoints, distinguished from each 
other by elaborate naming conventions, or multiple options, which may be confusing or hard to learn. 

We can tackle some aspects of the complexity of this interface by using tags. Notice that the user may 
not want to treat all rules in R equally. For example, suppose one rule b r should be used twice, and the rest 
exhaustively. Our solution to this scenario requires some help from the meta-language. We define in HOL 

BOUNDED (/; : bool) (n : a) — b 


and in ML 

datatype usage = UNBOUNDED 

I BOUNDED of int ref 

fun Atmost th n = < ... create | - BOUNDED th n ... > 

An invocation Atmost (b M) i. where i is an integer, creates the theorem b BOUNDED M n, where n is 
a variable named i. This enables us to invoke the rewriter (which has to be altered, see below) with a list of 
theorems as follows: 

REWRITE.TAC [Atmost r 2, ... ] 

The rewriting engine pre-processes each rule to see if any are tagged with usage information. Those that 
aren't are paired with the ML value UNBOUNDED, and added to the set of rewrite rules. (Each element in the 
background set is paired with UNBOUNDED, reflecting the idea that such rules should be used exhaustively.) 
A rule that is tagged with a usage restriction is paired with the ML value BOUNDED (ref n), where n is the 
supplied restriction. Once each rule has been mapped to being UNBOUNDED or BOUNDED, the rewriting process 
starts. W hen a rule is matched against the subterm being rewritten, it can be either unbounded, in which 
case the rewrite goes through, or bounded, in which case there is a check to see if the rule has been used 
up (Le., its reference cell holds ‘0’). If so, then the replacement doesn’t happen. If not, the reference is 
decremented, and the replacement happens. 

In HOL, only minor changes were made to the rewriting mechanism in order to have it process such tags. 
W hat is pleasant is that the code is completely backwards compatible: existing applications of the rewriter 
in tactic scripts do not need to be changed. 

As future work, we wish to add in a rewriting directive for conditional rewriting. There are essentially 
two ways to implement conditional rewriting in goal-directed proof. The standard approach demands that all 
conditions be proved before replacement takes place. This is usually the desired behaviour, but occasionally 
the proof of the conditions fails, and it can become an awkward business to get the rewrite to happen. The 
alternate approach assumes the conditions, thus ensuring that the rewrite happens, leaving the conditions 
to be polished off later. Accomodating the two styles would seem to require multiple entrypoints, but we 
envision having a Force tag that would signal which manner of rewriting should be used on a conditional 
rewrite rule. One interesting outcome is that it may be possible to perform induction proofs via forced 
and bounded higher-order rewriting (since an induction theorem has the form of a conditional higher-order 
rewrite). 

8 Conclusions and Future Work 

We have seen how some common implementation issues in higher-order logic theorem provers can be handled 
with a notion of transparent tagging. We hope that giving a name to a common practice will encourage others 
to come forward with their own tales of using K to support proof. 
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The 1 device is not without its drawbacks. For example, it seems best to restrict the scope of a tug s usage, 
tags are best when only their implementor is aware of their existence. Thus, eliminating a tag as soon as 
possible seems to be good practice. Otherwise, unrelated proof tools may need to know about the tags used 
by each other, making for a development nightmare. It is true that some tags, like those for numerals, do 
persist: however, they don’t seem to cause much trouble (perhaps that is because they represent constants). 

Another (related) worry is nest ing of tags. In that ease, the semantics of K mean that no confusion of 
meaning is possible, but confusion of proof tools may certainly happen. Foi example, what if an assumption 
is named twice? With different names? Tag creation and elimination could be made idempotent. but the 
issue remains, especially when tags supporting different proof tools overlap. 

A further limitation is that tags need to be well-typed terms. If that is a problem, one can use strings, 
uninterpreted constants, or the names of free variables in order to provide tags that can be externally 
interpreted. If. for example, one wished to attach hyperlinks in the logic to theorems, a string tag 

URL (t : bool) (s : string) = / 


might be a possibility. 

We have seen how tagged terms may be implemented: what about tagged types? To follow our initial 
insight, we need types that act like K. This may correspond to so-called phantom types, in which superfluous 
type variables are used to enforce extra invariants via type inference. The paper [2] provides a range of 
applications of phantom types in interfacing C to ML, including the use of type inference to enforce array 
bound constraints. Thus, like tags, phantom types are useful for building interfaces between a type theory 
and the outside world. It may be possible to create phantom types in HOL as well. 
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Abstract. The formalization of mathematics in theorem provers and 
proof checkers, including continuous mathematics such as real analysis, 
is sometimes undertaken purely for intellectual interest. For example, 
the Mizar Mathematical Library includes a large number of analytical 
theorems. But a surprising phenomenon is how useful noil-trivial math- 
ematics can be in verification applications. 

One might guess that for verification of concrete floating-point algo- 
rithms, only the most basic "algebraic" properties of reals and simple 
combination formulas for transcendental functions would be needed. But 
we will draw on our own experience to show that this is not so, and one 
needs a surprising amount of pure mathematics. Thus we can, should we 
so wish, justify the formalized development, of much apparently "imprac- 
tical" pure mathematics even in crudely utilitarian terms. 
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Abstract MathWeb is a svstciu which allows mathematical software programs to intercommunicate. 
The aim is to allow manual or automatic queries from, say, a higher order theorem prover to a first 
order theorem prover or from a computer algebra system to a theorem prover We present an imple- 
mentation of a basil- PVS service in MathWeb. The service offers a black box which takes P\ S-syntax 
conjectures and interprets the resulting PVS output as to whether the proof attempt succeeded or not. 
The main implementation allows access to the PVS Real Analysis Library and defaults to running the 
grind strategy (“strategy" is the PVS term for what is often called a tactic m other systems) on the 
submitted conjecture. Customisation to access other libraries and strategies is possible, and we present 
an instantiation of this to access Gottliebsen s continuity checker for the Real Analysis Library. We 
also give an overview of the difficulties of accessing PVS is this way with suggestions for abstracting 
the core prover away from the existing EMACS interface. 


1 Introduction 

In this paper we present an initial implementation of a PVS-Math Web-Interface [PVS-MWI] and details of 
the proposal for a full implementation of such an interface. PVS is a higher order theorem proving system 
designed for interactive use primarily in formal methods development. Theory developments in real analysis, 
however have made it a useful tool for work in supporting computer mathematical assistance but the need 
for theorem proving technology in this area lends itself more to a black box theorem proving system than an 
interactive theory development platform. In addition, interoperability with various other systems is important 
in this application domain. The MathWeb software bus is a useful broker and integration architecture or 
such systems and as such is an obvious platform into which to link the PVS system, and in particular the 

real analysis capabilities of Gottliebsen’s development [8, 9]. 

We begin with some background information on MathWeb in the next section and then proceed with 
background on PVS and the Real Analysis Library. Next we present some of the problems of running I VS, 
designed to be an interactive theory development system, as a black box prover in section 4. In sect ions o and 
6 we first present the proposed PVS-MWI and then the prototype implementation. Wehmsh by considering 
the ramifications of this work and future directions for such a development in section 7. 


2 Background: MathWeb 


The MathWeb software bus has been developed, primarily at the University des Saailandes, to act as an 
intermediary between various pieces of software which perform symbolic calculations of some form. The 
original aim was to allow theorem provers [TP] and computer algebra systems [CAS] to interact. Previously, 
a number of pairings of such systems had been connected but this necessitated working out the exact details 
of external communication for each system in turn. The advantage of a system like the MathWeb software 
bus is that any system connected to it can be connected to any other system without worrying about 
operating system level details of their communication. In particular, any system which has a straightforwaic 

command-line interface can be fairly easily connected to MathWeb. , 

The details of connecting systems together requires more than simply the operating system level o 
connections, of course. Problems which must still be addressed for each system include: 


* This work was supported by the EU Grant Calculeinus HPRN CT-2000-00102. 
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- Translation between the object languages of the TP or CAS. 

- Control of the processing occurring in each system. 

- Synchronisation of a mutual symbolic calculation effort. 

Use of the OZ language (using the Mozart implementation: see [12]) allows Math Web to provide a solid 
platform in which these problems may be addressed while at the same time providing a fully transparent 
system of communication on a local host, a LAN or fully distributed over the internet. 


3 Background: PVS Real Analysis Library 

First we consider the uses of formalisations of real analvsis in general and them give* details of the* formalisation 
in PVS. 


3.1 Formalisation of Real Analysis 

The formalisation of real analysis and related continuous mathematics topics, is currently an area of great 
interest. Most of the major higher order logic systems currently available have one or more efforts underway 
to develop a formalisation of real numbers, transcendental functions, or similar. This development stems 
from a number of different application areas, including: 


Formal Methods used to support the development of air traffic control systems. This requires a formali- 
sation of geometric aspects of air flight, which requires trigonometric functions as part of the library of 
underlying concepts: [3]. The development in PVS of a Real Analysis Library has been useful in such 
work. 

- Formal proof that a hardware implementation of the IEEE floating point operations require an underlying 
concept of the operations over the reals to be present to allow formal proof that the rounding operation 
is not introducing errors: [10]. This led to the development of a Real Analysis Library in HOL- Light, 
much of which has been ported to HOL-98. 

Development of t heories of real analysis, complex analysis and related topics are available or under current, 
development in PVS [5,8]. HOL (HOL-Light and 98) [10], Isabelle (Isabelle/NSA) [6], ACL2 (actually a 
variant called ACL2(r)) [7] and Coq. 


3.2 The PVS Real Analysis Library 

The particular work we are interested in here is the development of a Real Analysis Library for PVS. 
The initial work on this library was done by Dutcrtre [5]. PVS already included a base type of real as 
an axiom at ised sub-type of number. Dutertre developed various parts of fairly abstract real analysis. That 
development started with a theory of sequences of reals (PVS has polymorphic sequences as part of the base 
system), developed explicit convergence criteria for sequences and then functions on the reals, and finally 
defined abstract notions of continuity and differentiation. With some changes to make concepts such as 
continuity and differentiation more useful for concrete functions, Gottliebsen [8] extended this library with 
further work on real functions, including the definition of infinite sequences and power series. The definition 
of power series allowed an analytic definition of a number of the transcendental functions, including In, exp, 
sin, cos an tan. The properties of these functions were developed as a lemma data base to the point where 
they were sufficiently characterised that further lemmas can generally be proved without reference to the 
underlying power series. The definition of any new transcendental function would require a power series style 
of definition, however, and a similar background of properties would need to be added for the new function 
to be useful. 
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3.3 Automated Proving Using the PVS Real Analysis Library 

The PYS Real Analysis Library was primarily developed to support, research in improving the capabilities of 
Computer Algebra Systems [CAS] such as Maple and Mathematics As such, the arm was tc, coupie a CAS 
and PYS together to produce a stronger (i.e. capable of producing correct answers m mon tin.ums c . )• 
The original project looked primarily at the contents of the computational mathematics bemg considered 
by each system rather than at practical measures for coupling such system together. Th< u 1 1 y o 
these circumstances was as a black box which could handle logical side conditions on various computations 
In particular the inability of CAS to show satisfiability or unsatifiability of sets of constraints on rcal-^ued 
parameters with equalities and inequalities involving transcendental functions, causes great problems m tin 
area of definite integration (amongst many others). In addition, the same problem area of. ,1 . ofi,U 
loads to a need for a good continuity checker for parametric real functions, another area m which CAS an 

‘ >;U Th'e auUmiat h' proving features of PYS were originally designed to perform “routine-” tasks during inter- 
active proving. The scope of those ‘ routine” tasks has gradually increased to the point where these automatic 
routines can now handle fairly complicated problems without any user intervention. P\ S automated pro 
procedures build up in a hierarchy of rewriting, ground term evaluation and definitional unfolding. I 

level generic automated procedure which we are interested in is grind. This strategy has a large mmibcrof 
optional arguments which control the operation of the underlying procedures to guide the proof search. \\ hilt 
PYS his a strategy language in which specialised strategies may be developed, it is often more useful* 
use this language to define a special-purpose strategy which simply calls grind with appiopnate ^u >cn s. 
The continuity checker developed by Gottliebson [9] uses this method. Investigations continue into be. 

narameter settings for grind to cope* with satisfiability problems. . 

Recent work at the NASA Langley Research Centre and ICASE has led to some interesting development, 
in special purpose tools for automated proof of formulae involving real numbers. See [4] for de ai s. 


4 Running PVS as a Black Box 

As mentioned above, PYS was designed very much as an interactive system. The developers of thes^tem 
who are also themselves one of the primary user groups, use the system in this way On y a few small projects 
have tried to use PVS as a back end system with a different interface and as such, the integration of PAS 
as an automated system available via MathWeb produces some interesting implementations problems. This 
section will look at the structure of PYS and explain where the MathWeb interface should sit m the system. 

4.1 The Structure of the PVS System 

The main user interface for PVS is written in Emacs (also compatible with XEmacs)_ The core engine is 
written in Allegro Common Lisp and distributed as a run-time library only. The PVS development team 
are considering options for releasing the source code of the core engine, but it was not available ai t the ? tun 
this project was undertaken, although Owre of SRI has been particularly helpful m identifying the hooks 
between the core engine and the Emacs interface. On first, evaluation, the system is deceptively simple, and 
itiav be considered as shown in figure 1. 

Looking closely at the details, however, we see that there is not such a strong divide between the operations 
of the Emacs Lisp Interface and the Allegro CL core. The Allegro CL Coro writes information direc tl> 
temporary files, for instance, which the Emacs Lisp Interface then copies to the permanent storage position. 
Message passing is also not quite as simple as we would wish: the Allegro CL Core prints out large amounts 
of text delimited by message markers such as 

:pvs-msg :end-pvs-msg 

which are parse.] bv the Emacs Lisp Interface and displayed (or not) in Ihe correct manner (via the interaction 
ZL. 1 .he message bar o, written to Emacs bolters). In addition, as well as input from .the use . the 

Emacs Lisp interface controls the timing with the core engine by sending ^ 

engine know that it is ready to process the nest part of its output. Tl.e Allegro CL Core wans for these 

messages before it proceeds with the proof attempt. 
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Fig. 1 . A Naive View of the PVS System 


4.2 Design of the PVS-MWI 


The eventual aim of the PVS MathWeb service is also to be able to offer an interactive proof session. This 
would comprise simply the ability to perform interactive proofs and to parse the produced proof script. The 
theory management aspects, such as adding new theorems to a library, are not expected to be supported in 
this manner. For the moment, and as a first, step, however, we aimed at allowing the MathWeb server to send 
a problem m PVS syntax to a PVS core engine running as a stand-alone process, and to interpret the results 
as success or failure. This initial project aims to develop an understanding of the issues and to identify the 
aspects of PVS that are suitable for such an interface, arid those which require revision to ensure a robust 
system. 

Given that most PVS development and usage is expected to continue via the good interactive interface 
already available, the ability to talk to an external server such as MathWeb is seen as a side goal of the main 
development, but one which should not interfere with the primary development path. Thus we present a 
design here which would allow our aims of an automatic or interactive proof session to be sent to PVS. and 
the resulting proof script to be interpreted. Then we will present the aspects of PVS which are relevant to 
this design, and finally present the existing state of our interface, wdiich achieves the basic aim of allowing 
automatic proof attempts in PV S with the very limited result of checking for success or failure. The design 
presented here is to work with the PVS system in its current form. See section 7 for a discussion of changes 
t° ^ ie core engine which would allow a cleaner PVS-MWI interface without degrading with the existing 
interface. 


4.3 Existing PVS System 

Figure 2 shows a more detailed breakdown of the actions of the PVS Allegro CL Core and the Emacs Lisp 
Interface 

The Interface reads files from the permanent file store, which provide persistence across sessions for theory 
development, proof scripts and other support mechanisms. It also controls information flows into the Emacs 
buffers which hold the raw output of the Core Engine, the interactive session with the user and theory/proof 
files currently under development. The Core Engine outputs messages to the Interface (interpreted via the 
raw output buffer), and also writes proof scripts directly to the temporary file store. Most importantly of 
all, the Interface sends commands directly to the Core Engine. These commands include start-up routines, 
the loading of theory files and libraries, and proof commands. 
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Fig. 2. A Model of PVS Operation 


4.4 Automated Proving in PVS 

Before we consider onr proposed and initial impiemenied “ “ ET 

Inch as jrmd- Since PVS does not produce proof objects as such, but only proof ™pts, 

,e»d to problems — >» «’% “ ~at",~s ^ versions expand 

f •» r - ; hal ,hc af "°;: s 

mrnmmmm 

as well as an indication of success or failure. 


5 Proposed PVS-MWI 

T . ‘ f PV c fii_ Nnr ; s there anv requirement to write information to Emacs buffers. 

srrrss i, ™ ■" 

written by the Core Engine. The PVS-MWI also needs to communicate directh with E g • 
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5*1 The Automatic PVS Proof Service 

As mentioned above, we arc not aiming to provide a replacement for the existing Emaes interface Instead 
vve ami to Provide a P\ S server which will allow proofs to be performed either automatically or interactively 

™ 0 ( °!r • 1<m ’ H , mHSt rertai, V Via aMother t >ro K rani - While much of the Emaes interface deals 
developing theories and associating proofs with their formulae etc., we are not concerned with such 

ssues. How even , there is one issue regarding theories that we must address: the context in which a formula 

1> ?rWiH ‘ S , Valld ' l \ * s U,, lk( ‘ lv that ma ny ^ers will wish to use simply the base PVS logic and initial 

trh n P T'- n °f S) ° nly - 11 iS ,nore likdv that a P af tieular theory context will be required, 

f s i< ical analysis binary. the context offered bv the current version of the PVS-MWI 

Since there is a substantial time-lag in loading large theories such as the Real Analvsis Library it is 

SST .: a< ; h T7 X - WiH actual,y be aa ^ with the appropriate theory pr" 

loaded. Tims, instead of simply asking for a PVS service, the client program would have to specify PVS+Lib 

tvm oft* f 1IUS r h ° Rmls - cnsure effi( ' ient communication, the ideal interface should also indicate the 
i oima ion expected as a return. There would be no point in returning a proof to a computer algebra 

chsSv Z 1 I 1 St T << 'f W reaS m>ga . r( ? Ur " S prover S<>rvires to r cturn an appropriate proof object. We can 
classify the modes of operation required of the interface as shown in table 1 below. 


Query Mode 

Responses 

Prove Positive, No Object 
Prove Posit i ve& Negative, No Object 
Prove Positive, Object. 

Prove Positive^: Negative, Object 

True/Unknown 
True/ Unknown /False 
True/Un known A: Proof 
True/Unknown/False&Proof 


Table 1 . Modes of PVS Interaction 


As mentioned above the modes which require the return of a proof object (in the case of PVS an expanded 
Tthe^ c St a ? i,able) WU1 reqUir< ‘ 3 slightly di^ent form of the strategy command passed 

have five argumUtT™ ThUS ^ C ° mmand m 3 chent wh,ch P assos a conjecture for proof to PVS should 

1 the conjecture (a formula in PVS syntax or another syntax which the PVS-MWI can convert into PVS 
No default value; 

2 ‘ a “ en,P ‘ “ l>n ' V< ' ' he f °™ Ula TtUe is “ »«™Pt to prove the 

Default X- lSToS: n0 ‘ retUn ‘ S Tn “ “ • P™of: 

3. the name of a strategy to call to attempt to prove the conjecture; 

No default value; 

4. the name of the theory in which context the proof of the conjecture should be attempted- 
Default value: prelude; 

5. a flag to indicate whether a proof object should be returned; 

Default value: False. 

Should a PVS-MWI contain a translation mechanism from, say, OpenMath notation into PVS notation then 
cllt!!' 7 7 g Syn T, in Stating the con i ecture may be- needed. Likewise should the interface be 
format TOuTdbTST ° iJeCtS ” d,fferent ^ ™ ^ argument indicating the required return 

Note that the lack of a default value for the strategy to be applied allows for an “empty” strategy to be 
passed in to indicate that a user wishes to perform an interactive proof. 

The current interface must perform a fair amount of processing of PVS I/O at start-up and during each 
proof attempt. In the long run much of this work should be ameliorated with access to extend the PVS 
V egro Common Lisp Core with appropriate flags indicating the status of PVS in a “black box” mode. 



A PYS Service for MathWeb 


153 


It should ho noted that there aro a numhor of 11011 -standard case's to ho eonsidorod for a full-foaturod 
automatic proof service: 

- A conjocturo may ho submitted that is syntactically or typo incorrect. 

— PYS does not attempt to prove a conjecture false, so any false conjecture submitted will simply load to 
a failure of proof, indistinguishable from a case where the proof strategy is not strong enough to prove 
the conjecture. 

6 Current Version of the PVS-MWI 

In this section we will describe the' current minimal implementation of the P\S-M\\I. This is a working 
service, available for installation as part of YlathWeb, but includes only parts of the full set \ ice desciibed in 
the previous section. See the later section 7 for details of ongoing development in this project. 


6.1 Starting PVS 

Originally, running PVS in a shell required the execution of the Allegro Common Lisp image directly, rather 
than invoking the distributed shell script which normally starts PYS. Since then Owre has added a switch to 
the shell script which runs PVS as it stand-alone program: pvs -raw. This still only starts the core engine of 
PVS, however, and there art' various steps which must he then taken to put the system into a usable mode 
as a proving tool. The first of these has been made obsolete by the most recent release of PVS (2.4). \\e art' 
in the process of updating the PVS-MWI to take account of this release. 

1. Load the latest patch files (if patch files are present). 

2. Change to the "Package" PYS (see the Common Lisp documentation [13] for a description of packages). 

3. Change the working directory in which PVS operates (in interactive sessions this is called the context). 

4. Run a simple test proof of “1=1” using “(grind)” in the context of the Real Analysis Library. This 
pre-loads the entire library into the current image. 


6.2 Successful Proof Process 

The PYS Core Engine function prove-f ormula-decl is the function called to start the proof process. The 
arguments of this function include the conjecture for which proof is to be attempted, the PVS theory which 
forms the context of the conjecture and proof attempt, and a strategy which is to be applied. 

At specific points in the proof attempt process, the PYS Core Engine outputs a message indicating to 
the Emacs interface that it is in a particular state and ready to proceed with the next stage of the proof. 
At each of these points, the PVS Core Engine expects a. token from the Emacs interface to indicate that 
it is ready to proceed with the next phase of the proof. This interaction is due to the requirements of the 
Emacs interface to display messages, update the interaction buffer, and copy text to and from temporary 
file storage. The sequence of interactions is shown below. The text in courier typeface is the output from 
the PVS Core Engine (. . . indicates other lines appearing first). The conjecture being proved is NOT (0=1). 
by using the strategy (grind) in the context of the Real Analysis Library. 


:pvs-msg Formula typechecked :end-pvs-msg 
:pvs-eval (setq pvs-in-checker t) : end-pvs-eval 

This shows that the Core Engine has completed type checking of the conjecture. Note that this does not 
necessarily mean that type checking has succeeded, simply that it hasn t failed. See section / for a discussion 
of this. The next line indicates that, the Core Engine is now entering proof check mode. Once a token (“t 
is appropriate) has been sent to the Core Engine, we get the following: 
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test : 

{- 1 } (0 = 1 ) 


Rerunning step: (GRIND) 

Trying repeated skolemization, instantiation, and if-lifting, 

Q.E.D. 

:pvs-eval (setq pvs-in-checker nil) : end-pvs-eval 

The name of the conjecture being proved (important when the interface is maintaining a record of a theory 
and linking a proof to lines of a theory file) is test (the specification of the conjecture in the argument of 
prove-f ormula-decl is required is have a name). The initial form of the sequent in the proof is printed and 
the steps to be automatically attempted in the roof are shown (in this case simply the single step (GRIND)). 
The progress of the strategy is reported (Trying. . .) and then success is indicated with Q.E.D. followed by 
the fact that the Core Engine is dropping out of proof checker mode. Again, a token is sent to the Con' 
Engine, resulting in the following output: 

:pvs-eval (pvs-ready) : end-pvs-eval 

A final token submitted to the Core Engine returns “T” . This is the evaluation result of prove-f ormula-decl, 
but is not an indication of the success or failure of the proof attempt , simply a place-holder return value. 


6.3 Unsuccessful Proof Process 

The above sequence shows what happens when PYS is presented with a conjecture which is provable by 
the strategy requested. This is not always the case, however, so we must consider how the Core Engine acts 
when presented with a conjecture improvable by the strategy. This can be because the strategy is not strong 
enough to prove a true conjecture or because the conjecture is false. Note for our initial implementation of a 
PVS-MWI we have not implemented a recovery scheme for cases where an ill-formed conjecture is submitted 
(either with a syntax error or an identified type-checking error). Nor has recovery from an apparent “infinite 
loop" been implemented by sending a break signal and recovering from the resulting break level of the Allegro 
Common Lisp session in which the Core Engine runs. 

To demonstrate an unsuccessful proof attempt we will present the interaction which occurs when the 
conjecture 0=1 is presented to the (grind) strategy: 


:pvs-msg Formula typechecked :end-pvs-msg 
:pvs-eval (setq pvs-in-checker t) : end-pvs-eval 

An identical start to the previous sequence, with the formula correctly type checked and the Core Engine 
reporting that it is now in proof checker mode. 

test : 

| 

U> (0 = 1) 

Rerunning step: (GRIND) 

Trying repeated skolemization, instantiation, and if-lifting, 
this simplifies to: 
test : 


[ 1 ] (0 = 1 ) 

♦♦♦Warning: Fewer subproofs (0) than subgoals (1) 
No change on: (SKIP) 
test : 

| 

[ 1 ] (0 = 1 ) 

Postponing test. 
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test : 


[ 1 ] (0 = 1 ) 

:pvs-eval (setq pvs-in-checker nil) ’.end pvs eval 


Havin'’ received a token the (grind) strategy this time fails to prove the conjecture. The critical point here 
is actually the lack of an appearance of Q.E.D. being the easiest method of detecting failure. Another token 
is then sent to the Core Engine, which has indicated that it has dropped out of proof checker mode. 


Would you like the partial proof to be saved? 
(***01d proof will be overwritten.***) 

(Yes or No) 


Now we see the unwanted interaction designed for the full Emacs interface coming .to play ask mg , us 

for instructions with regard to the partial proof developed in attempting to prove the conje.tm . Th C re 
Sehm acmallv does verv little d, 'pending on the answer here. The primary operation is earned out b the 
Emacs Interface in copying the temporary proof file into the appropriate part of the proof hie underlying 
the current theory. On sending “yes" the Core Engine returns: 


Use M-x revert-proof to revert to previous proof. 
:pvs-eval (pvs - ready) : end - pvs - eval 

For the purposes of a replacement interface, however, “no 
Core Engine gives: 


is a more appropriate response, to which the 


:pvs-eval (pvs-ready) :end-pvs eval 

After either of these, a further token is required 
loop, with the final response of: 


to reset the Core Engine to it’s top-level read-eval-print 


("" (GRIND)) 

that is, the partial proof. 


6.4 The Implemented Basic PVS-MWI 


Thus the basic PVS-MWI that has been implemented has the following features. 


- Only the actual conjecture (in PYS syntax) is a required argument. 
" text. Default values of the Real Analysis Library for the context. 

included. 

- Three main functions arc provided: 


To this is added the “test: lemma 
and (grind) for the strategy are 


Function 

Description — 

prove 

Simply attempts to prove the conjecture and returns iiue it suc- 
cessful. If this fails it. returns “I Don’t Know! ’ 

provetf 

Attempts to prove the conjecture True and returns Tiue if sue 
cess ful. If this fails then it attempts to prove the negation of the 
conjecture and returns “False” if this succeeds. If both fails it re- 
turns “I Don’t Know! — 

provects 

This assumes that the conjecture is of the torm ot continuity of a 
real-valued function. It calls Gottliebsen’s continuity-checker (cts) 
and returns “True" if this succeeds and “I Don’t Know” otherwise. 
Proof of discontinuity has not been implemented so proof of the 
negation here is not supported. 


- In all cases where a proof attempt fails, the PVS-MW I answers 
recording the partial proof and correct ly resets the Core Engine to 


"no” to the question posed about 
the top-level prompt. 
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7 Conclusions and Future Work 


The existing interface is simply a prototype and requires a fair amount of further work to be truly useful. 
. eveitlieless. the exercise has proved very useful in a number of ways, which we will consider here' before 
addressing the future direction of this work. 

Taking a system such as PYS which was designed as an interactive theory development platform with 
a specific Emacs interface, and allowing its use as a black box back end theorem prover has proved more 
complicated than might be initially expected. However, the areas where optional settings may be added in 

to make this an easier proposition have now been identified and development of PVS in this direction should 
not prove difficult. 

Related work on system specific interface such as the Maple-PVS link [1] should also benefit from this 
exploration of the P\ S system arid developments in this area. 

Various aspects of the Math Web software bus have been tested and occasionally broken during this 
development. This paper has not focussed on such details as race conditions between tin' interface and 
the PVS Core Engine; zombie PVS processes caused by failures of the broker architecture; and similar. 
Nevertheless the development of the Math Web architecture has undoubtedly benefit, ted from including PVS 
in its family as proof system server. Developments in using other higher order systems as servers in Math Web 
will be easier following the lessons learned here. Specification of a generic black box automated theorem 
proving service derived from the PVS service is one concrete outcome for the Math Web system from the 
prototype PVS-MWI. 


7.1 Exploration of PVS as a Back End System 

As mentioned many times above. PVS was primarily developed as a theory development platform and it will 
certainly continue to be used in such a fashion. Indeed, further enhancement of the capabilities as a black 
box system require a good theory development platform to be available. However, identifying the areas of the 
existing P\ S system where the theory development platform is unnecessarily embedded in the core engine 
will prove a useful exercise in informing future development of PVS. Once a theory has been developed it 
is quite often useful to allow black box use of automated strategies in the context of that, theory and the 
work shown here will hopefully allow further development of the PVS Core Engine to support this need. 
Availability of PVS theories as black box systems should also stimulate development of more and more 
complicated theory systems in addition, benefiting the PVS community as a whole. 

7.2 Implementation of the Full PVS-MWI 

The main task of the development of a full PVS-MWI would be the development of an interactive proof 
ability. Extension of the existing prototype to cover black box proving as shown in section 5 should be 
relatively straightforward, providing changes to the PYS Core Engine as described below are undertaken 
Some rationalisation of the existing system would be required, most specifically a separation from the 
current dependence on the Real Analysis Library as the default context. An early decision would need to 
be made as to whether a generic PVS prover might be offered or whether specific provers offering a single 
context would be better. Each has its advantages, and the decision would also be informed by the changes 
that might, be made to the Core Engine of PVS. 

It had been thought that automated proof checking using prove-f ormula-decl generated separate type 
checking conditions (tecs). On communication with PVS developers, however, it turns out. that tecs generated 
when performing a proof with this function are folded into the goal, so that, whenever “Q.E.D.” is generated, 
oim can be sun that am tecs have also been verified. However, this behaviour may be the cause of occasional 
infinite loops during the automated proof attempts. A more sophisticated approach to using PYS as an 
automated back end proving system might, do something more intelligent with the tecs. 

7.3 Proposed Developments of the PVS Core Engine 

We list here suggested amendments to the Core Engine which are feasible without altering the existing Emacs 
interface code substantially. 
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- Switching off the printing of most of the messages. 

- Not requiring a token passed in at the various points noted above. 

- Ignoring the "partial proof' to he saved or not when a failure of proof occurs. 

- A robust timeout setting returning a failure of the proof attempt after a certain number of CPU cycles. 

- Defining a new proof function which returns a T or NIL as well as the proof if successful. 

In addition. Allegro Common Lisp run-time images of the Core Engine with various libraries pre-loaded 
would improve the efficiency of start-up of a PVS-MWI which offered services in those contexts. 
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Abstract. We have finished a constructive formalization in the theorem prover Coq of the Funda- 
mental Theorem of Calculus, which states that differentiation and integration are inverse processes. 
This formalization is built upon the library of constructive algebra created in the FTA (Fundamental 
Theorem of Algebra) project, which is extended with results about the real numbers, namely about 
(power) series. 

Two important issues that arose in this formalization and which will be discussed in this paper are 
partial functions (different ways of dealing with this concept and the advantages of each different 
approach) and the high level tactics that were developed in parallel with the formalization (which 
automate several routine procedures involving results about real- valued functions). 


1 Introduction 

In this paper we show how a significant, part of real analysis can be formalized in Coq. We deal with differ- 
entiation and integration, proving the Fundamental Theorem of Calculus (which states that differentiation 
and integration are in some sense inverse processes) and Taylor’s Theorem (which allows us to express a 
function in terms of its derivatives while giving an estimate for the error), as well as defining some standard 
constructions such as function definition by power series arid as an indefinite integral. 

In parallel with the development of the theory some automation tools (tactics) were built with two aims: 
allowing a significant part of the proofs to be done automatically and enabling the proof assistant to perform 
the kind of computation that the average person working in this field can do. With these tools, Coq can 
prove a large number of results involving derivatives and calculate the derivative of functions in a wide class, 
looking also at the context, where this computation is being done. We hope to extend the system in a near 
future to be able to solve the problem of integrating rational functions, providing both an answer and a 
proof that this answer is correct. 

The basis for this work was chapter 2 of Bishop’s hook on constructive analysis ([3]). The formalization 
was built upon the algebraic hierarchy developed at the University of Nijmegen, described in [7] and available 
in the Coq library, which included most of the results about real numbers that were needed, namely most 
of sections 1 to 3 of [3] (where real numbers are defined and their main properties are proved); new results 
about series were formalized, and sections 4 (dealing with continuity, sequences and series of functions), 5 
(differential calculus and Taylor’s theorem) and 6 (integration and the Fundamental Theorem of Calculus) 
were completely formalized. Work is in progress regarding section 7 (which is concerned with exponential 
and trigonometric functions and their inverses). 

Our work centered on formalizing the definitions of basic notions in differential and integral calculus, 
including notions of: 

- continuous function; 

- derivative; 

- differentiable function; 

- Riemann integral; 

- (convergent) sequence or series of functions; 

- Taylor sum and Taylor series of a function. 

This author was supported by the Portuguese Funda^ao para a Ciencia e Tecnologia, under grant SFRH / BD / 
4926 / 2001 . 
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U** ,1k*. definitions. many ,1, .warns to this area * formally prove side Coq: .to- most Import-. 

among these were: 

_ the preservation of continuity through algebraic operations on functions; 

- the uniqueness and continuity of the derivative function, 

_ the derivation rules for algebraic operations on functions and the chain rule for composition. 

- Rolle’s Theorem and the Mean Law; 

- int.egrability of any continuous function, 

- the Fundamental Theorem of Calculus; 

- preservation of limits and derivatives through hunt operations; 

- convergence criteria for series of functions (the ratio test and the comparison test): 

- Taylor's theorem. 

to 2 W briefly describe soil,., characteristics „f this tortodtottioa, "«'"<li>.K the consequ. « " r 

.. «. *. - ■; 

“ most of the fu.te.iom of analysis me purti.l (for example. the logan , and 

to section 3 wo present the drlferen, approaches that were stud.ed and why we chose the 

" s ”“ 4 describes how procedures were built that deal with a large class of the most common goals 
whid, 2w up in the area of differential calculus. At the end. we will briefly eomp.ro ,1ns formal, z at, on w.th 
similar work already done in other proof systems. 


2 Formalizing Mathematics in Coq 


Before we go into the specific details of our work, we will briefly discuss some specific Coq issues that influence 

the cZ^^Z\b^TX^ system with inductive types called the Calculus of Inductive Construe^ 

tions (CIC) Through the Currv-Howard isomorphism, proofs are identified with terms am P ro ° 1(( 1 g 
cons,,,.'. , ion of a proof then becomes simply .ho interactive construct,. a tern, 

Wh to the CIC (hOTarnto Sn universes for terms: Set and Prop. Set is meant to be the type for sets 
JoZ«n>nZ ™ want to reason about: Prop is the type of propositions There ,s .also an rnhm.e 
tauK {iype(i) tUll) such that both Set and Prop have type Type(O) and Type(r) : Type(, + 1). 
i nf tv'-not: in this family will he irrelevant in this paper. 

TV logic associated with the CIC through the Curry-Howard isomorphism is 

f ° 'rfiemaV eharaetdisdc of croisumctive^easoning is the absence of proofs by contradiction. All proofs haee 

satisfying P, then it is also natural to have an operator that allows us to extract such an t. emeu rom t . 

^Unfortu*^ does not allow us to define an operator of this kind with type Prop -> Set for two 

diff^ent^eawns Vt a mathematical level, consistency of the system requires such an operator no to be 
allowed to exist (see [4], pp. 81-83). On the other hand, Coq comes with a program extraction mechanism 

1 An approach following tlie first alternative was independently chosen by Micaela Mayero. see [11]. 
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(biiofiv described in Chapter 17 of [4]) which allows programs to bo derived from informative proofs- for 
efheioucy reasons, t ins mechanism assumes that proof objects (living in Prop) are irrelevant, as they contain 
no computational interest. The existence of this operator would undermine this assumption 

Another problem is equality. In type theoretical systems, the natural equality to use is Leibniz equality 
(given x,y : .4. x -y iff VP : A -> Prop.Pir o Py): however, this turns out to be too strong a concept 
lor most purposes. Therefore, we have to define ourselves a structure with our own equality This is done 
through the notion of setoid: a setoid is a pair (5, =. s ) where =. s is an equivalence relation on 5. 

F<>r the purpose of formalizing real analysis, equality turns out actually not to be so basic a notion, as it 
is undeeidable on the set of real numbers. However, given two real numbers it is always possible to tell when 
they are distinct (although if they are not distinct we may never know). This motivates us to use what arc 
called setoids with apartness : setoids where a second relation #. s , called strong apartness, is defined, with 
tlio following properties: 


- irreflexivity: for all x : 5, ->(x#. s -x); 

- symmetry: for all x.y : S, if x # s y then y# s x: 

- co-transitivity: for all x,y, z : S, if x#sy then either x#§z or z#sy: 

- compatibility with equality: for all x,y : S, x =$ y iff ->(x# s y). 

The last property actually allows us to do away with equality altogether, although it is not usually done. 
Functions and relations on setoids are usually required to reflect this apartness relation: that is if / is 

a (unary) function from a setoid 5, to a setoid S 2 , then the following property holds: for anv two elements 
x, y : S ' 2 * 

f(x)#Sif{y) -4 x# Sl y . 

This property is known as strong extensionality of /. Predicates in general might not be required to have 
a similar property (and indeed in many interesting cases they do not), but sometimes the following weaker 
condition, known as well definedness , is required: for all x<y : S, 

x =s V -» P(x)-*P(y) . 

From now on. we will use the term “setoid” to mean “setoid with apartness” and denote the equality 

and apartness relations in a setoid simply by = and # respectively whenever the carrier set is clear from the 
context. 

At this point we run into another problem of Coq. These definitions work out nicely, but it turns out 
that if we want to use equality and apartness in a nice way they cannot have type S-tS-tProp. as would 
be normal for relations. For this reason, and our desire to use the weak form of the Axiom of Choice which 
we already mentioned previously, we chose to use also Set as the universe for propositions and define our 
logical connectives to work in this universe with the usual properties. 


3 Partial Functions 

In our work we only consider partial functions from one setoid to itself. The reason for this is that we are 
mainly interested in working with real-valued real functions, which satisfy this condition; but generalizing 
to arbitrary partial functions is quite straightforward and will be done in the near future. 

3.1 How to Define Them 

Throughout this section A will denote an arbitrary setoid. 

The main characteristic of partial functions is that they need not be everywhere defined. Thus, it is 
natural to associate with each partial function / : A A a predicate dom f : ,4 4 Set. 

In the algebraic hierarchy which we started from, we have a notion of subsetoid as being the subset of 
elements of a setoid S satisfying some property P with the equality relation induced from 5; formally, an 
element of a subsetoid is a pair (x,p), where x is an element of 5 and p is a proof that Px holds. Using 
this notion, it, seems natural to associate every partial function / with a total function on the subsetoid of 
the elements of which satisfy dom f . That is, the type of partial functions will be a dependent record type 
looking like (in Coq notation): 
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Record PartFunct := 

{dom : S->Set; 
dom_wd : (pred_well_def S dom) ; 

fun : (CSetoid_f un (Build.SubCSetoid S dom) S)} 


Hero, dom is the domain of the function; the second item of the record simply states that this predicate is 
well defined* : and the third item is a sotoid function from the subsetoid of elements satisfying the predicate* 

'° Then functional application will be defined as follows: given a partial function /. an element x:.4 and a 
proof H : (dom / x). f{.r) is represented by the lambda term 


(fun / ( x , H)) . 


where fun extracts the subsetoid function from the partial function record. 

There are several problems with this definition. One of them is that proofs get mixed with the elements (m 
the subsetoid construction), which does not seem very natural from a mathematical point of view (where we 
normally forget about the proof, as long as we know that it exists): another important one is that the terms 
that we construct quickly get bigger and bigger. For instance, if we have two partial functions /, <7 ; Af>A 
and we want to compose them, the relevant predicate dorriyoj will look like 


dom yo f := \x:A.(3Hf :{d<rm f x).(dom g (fun / (x, ///)))) - 

Assuming that for some x : .4 we know that H has type (dom gof x), that is. H is a pair consisting of a 
proof ///of (dorn j x) and a proof that (dom g (fun / (x, ///))), then, denoting by tt, and 7i r the left and right 

projections, (// ° /)(x) will reduce to 

(fun g ((fun / (x, (717 //))),( 7 r r //))) . 


This last expression has several unpleasant characteristics, namely it is totally unreadable and very 
unintuitive; the fact that we are simply applying g to the application of / to x is totally hidden among the 
pairing and unpairing operations and the proof terms appearing in the expression. Also, if / and g happen 
not to look at the proof at all (as is the case if they are total functions), they still have to apply projections to 
recover the argument from the setoid element. This makes the simplification procedure very time consuming. 

Thus, a. different approach is needed, and we turn to a common alternative which has already been used 
for example in the Automath system (see for example [2]). As before, we associate to every partial function 
/ the predicate dom j , hut now we identify / with a function of two arguments, a setoid eleme nt anc t le 
proof that it satisfies dom /. That is. our type of partial functions will now he. 


Record PartFunct := 

{dom : S->Set ; 

dom_wd : (pred_vell_def S dom) ; 

fun : (x : S) (dom x)->S; 

fun_strx : (x , y : S) (Hx : (dom x))(Hy:(dom y)) 

(((fun x Hx) [#] (fun y Hy) ) -> (x [#] y) ) } . 

Ill this definition, dom and dom.wd are as before, but the last item of the record type (which was itself 
a record) has been unfolded into two components: the function itself (as an element of a product type) and 
the proof of strong extensiomility of that function (which was previously hidden in the type of the setoid 
function). Given /, x and H as before, functional application now looks like 

(fun f x H) . 

which differs from the previous representation in that we removed one functional application (the pairing 
operation) and that the element x and the proof H are kept completely separated. This means that, for 

- Although this is not required from the predicate in order to build the subsetoid. it turned out to be fundamental 
for our work, namely to prove results about composition the chain rule for derivative, for example. 
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example, if / is total thou it can bo computed in a much simpler way. because x is directly available and no 
extra reduction is needed to got it. 

Also comparing with the previous example, the application of a functional composition can be written 
more nicely given /. r/, x and H as 


(fun g (fun / x (tt, H)) (t r r H)) . 


Notice that in many eases we won t even need to perform any computation on (717 H) and (tt,. //), because 
we won’t need to look at the structure of these' proofs. 


3.2 Working with Function Domains 

Once we have 1 partial functions, natural operations with them immediately suggest themselves. The most 
obvious one (which we have already mentioned) is composition, but algebraic operations (defined point-wise) 
arc 1 also important, at least from the analytical point of view. However, as soon as we try to define this it 
turns out that it is useful to do some work just with domains. 

Since we have identified function domains with predicates, it turns out that what we need is simply a 
mapping between operations on subsets and operations on logical formulas; that is, given predicates P and Q 
that characterize 1 subsets A and } of A we want to define predicates that characterize the sets A nL. A' Ub. 
A, 0 and the property A" C Y. These can be simply taken to be A x:A.(P x) A (Q x), A x:A.(P x) V (Q x ), 
A.r:A.T, Ax:A_L and A.r: A.(P x)->(Q x ). respectively. These constructions preserve well definedness (that 
is, if P and Q are well defined then so will all the predicates defined from them). 

As we are concerned with real analysis, it is also important to look at the specific kind of domains we 
will find. Constructively, it turns out that the most important one is the compact interval, which can be 
characterized by two real numbers a and b and a proof that a < b. The predicate corresponding to the 
interval [a, b] is, of course, simply Xx :IR.a < x A x < b. 

The reason for this domain to be so important is that all function properties (continuity, differentiability, 
etc.) are always constructively defined for compact intervals. Bishop argues (see [3]) that point-wise definitions 
make no sense in constructive mathematics for the reason that equality is undecidable, and so the information 
that a function / is continuous at some point x is useless because most times we will not be able to know 
whether we are exactly at x or not. However, if we work with compact intervals we will often be able to tell 
that we are inside them (unless we happen to be exactly on the boundary), and so use that information. 
Another important reason is that constructively it is not necessarily true that e.g. point-wise continuity in 
a compact interval implies uniform continuity in that interval (a counterexample can be constructed with 
some extra assumptions, see for example [1]), and so in practice it is more natural to begin with the uniform 
concept altogether. 

The other important kind of domain is the interval. In practice, it is difficult to find examples where we 
really want to work in a domain which is not an interval or a union of two or three intervals, and the main 
operations (differentiation, integration) and theorems (Rolled theorem, Taylor’s theorem, the Fundamental 
Theorem of Calculus) always require that the function (s) involved be defined in an interval. 

We model intervals as an inductive type with nine constructors, corresponding to the nine basic kinds of 
intervals: the real line, the left infinite open or closed, the right infinite open or closed and the finite open or 
closed on either side. To each kind of interval a constructor is associated: for example, finite, closed intervals 
are identified with applications of a constructor clcr 3 of type II a, b : JR. interval. To each of these the 
obvious predicate is associated, and a property P defined for functions in a compact interval is generalized 
by 

P f := (A/ : int, / : fun)(Va, b:JR)((a < b) -> ([a, b] C J) -4 (P [a, 6] /)) . 

This approach implies that we often have to state very similar lemmas for properties holding in compact 
intervals and in arbitrary intervals. This is not felt as a disadvantage, however, and is in fact quite close to 
Bishop’s formulation, as most proofs of such properties require distinct reasonings for the compact and the 
general case. 

3 Closed Left Closed Right 
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4 Automation 

xv, wil] „„w mm. what kin, Is of ««* reasonably oxpm to I- a.m.inaUclly !>«>'"' and how 

and q to prove the relation . . (1) 

q is the derivative of /. 

j t^thc st at or non t of every lemma that all the functions involved are continuous. Tins means that «c <‘M>< ( t 

to come quite often across goals such as *2) 

/ is continuous. 

Finally, the third goal comes as a typical side condition of the lemmas we must apply to prove- any 
statement of the previous two kinds: given a set X and a function /. prove that 


X C dorn{f). 


(3) 


In order gc, a better understanding of why goals of type 3 show up » often 

define equality of two funct This concept is parameter, zed by doom , s^ at », f 

f mA a and su bset X of 1R. we sav that / and g coincide on A (/ = \ g) the.} arc ocn 
fhey^oineide on every point of .V. that is. for any element a : .V anti any appropnate proof terms H. ami 

K ' V,:xV//..//; /(*, H x ) = g{x, H' t ). (4) 

Two comments art- due on this definition: 

', uld b( ( ,nual in everv set to the undefined function, and no substitution properties would hold. 

% ould be equal in < ACT > M ; 1 1 definP(i in x is to make proof development easier. 

- The reason whv we explicitly state that J and g are uuim u -t ... , , n „. li; ,.c 

This way, we are left with three independent goals to prove: the two inclusions and (4). 

prove independently. 

If we did not state the inclusion explicitly, then we would only have to prov. 

V x: .x3 h x .h' x f(x,H I ) = g(x,H x ) . 

which differs from the third one in that the proof terms are existentially quantified. However, the mas- 
;,m,al this goal much more difficult to prove and less suited to automat,,,,,, wh.eh ,s 

why we chose the first approach. 

. j i i?i (o\ Tvninallv thev are proved bv looking at the algebraic structure 

We begin bv considering goals like (o). I\picali\. tn y \ . j / / \ 

z:^ <0 up, but these too are usually take,, care of by one of a sum,, 

algebra,,' structure, there is also a smail uuu.ber of results we can use. namely the fa«s 
that 2tnd identity fnuetions are defined everywhere ami that any funet.on winch ,s coutmuous ,„ .X . 

u: ^ 

1 Like if / =.* !) and / is continuous in X then so is g. 
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when the structure off is too complicated. In those situations, typically the user has to break down / in 
sinallei parts by himself, and then invoke the automatic prover. J 

Goals like (2) work m quite a similar way, and have been treated in the same way 
hen we turn to goals like (1) however, things turn out to he quite different. From a naive perspective 
, ™ d <X1><> llus situation to he similar to the previous ones, as we intuitively reason in this situation 

U t SU,g * SniaJ1 "? ° f ^“imas-the derivation rules. However, when we analyze the situation more 

not SI “. 1P ° as 1<)(,ks ' a * W( ‘ sh(nv with a small example. Let / and g he functions everywhere 

l.hrnd by the rules /(.r) = 3* + 4 and g(x) = 3. respectively. If we want to prove f = g. then we would 
like to begin by applying tfm derivation rule for the sum; however, in order to do this we also need to have 

stuck " ' ,S ' SU,n tW ° ° ther fuiH:tion ‘ S on the ri S‘» side, and this is not the case. Hence we are 

The trick to to this is, obviously, to replace g by what we get if we differentiate / by using the differen- 
tia ru es m this case, by /i such that h( X ) = 3*1+0. Then we can easily prove that /' = k and wo a o 
le ft with the goal g = h, which is also easy to prove. The problem, then, amounts to finding h 

Intuitively, we would like to make some kind of recursive definition that looks at the algebraic structure 
of /. However there is no inductive structure in the class of partial functions, so this is not directly possible 
owe vc r, the Coq tactic language allows us to do something similar: we meta-define (that is. we define in 
it me .a- language) an operator that looks at the structure of / and correspondingly builds h. This operator 
cognizes algebraic operations, functional composition and can look at the context for relevant information 
( or instance, if there is a hypothesis stating that for some functions /, and f, the relation f[ = /., then it 
will use f, as a derivative' for /, ); however, the proof is still left to be done bv the user 

• r «n °« ’ r‘ In ° re P °r Crfu1, appr0ach is t0 use ^^ion (a method which is described in full detail 

ancf ' u‘,T ani01 1 th< ’ r ‘ aSS ° fa11 Partial functions thoS(> whore derivative we know how to compute 
and model this as an inductive type VT. This type will have not only constructors for constant and iciciiHtv 

10118 ; llld t al T L U ' ° peratlons 0,1 these ’ but al ™ «P^ial construc tors that allow us to add anv 
function about which we know something from the context. This will allow us. for instance, to prove that 
(2/) - 2 g if we know from the context that f = g. 1 

T we wiP define two operations: a canonical translation map [•] .- VT -+ (IRy^IR) to the real valued 

E for eve^T differe,ltiation operator ' : VT -+ VT with the property (stated as a lemma) 

[s'] i s the derivative of [,sj. ^ 

such°irM-V"7, TT *° the f °!°r is: given a fun < :tion f- ho- do we determine an element , : VT 
in Ton ,e ~/ i J h ° W < an T dcbnC a (partial) inverse to H ? Again, this is done at the tactic level 
‘ Vn f T ? ° Perat0r by taS " analysis that looks at th<> structure of / and breaks it down- 
. Aer fandhan a |K e hraic operator, constant or identity function, it replaces this by the corresponding 

7i rz it findS i a fUnCti ° n that U knOWS -‘hing about (that is! an expressZte 
f ) it tries to find an hypothesis in the context that allows it to use one of the two special constructors 

message hlDS W ° ’ W ° ge * U,deed an elernent * with the required property; otherwise we get an error 
W ith these tools we can then write down our tactic as follows: given / and g. 

1* Find a* : VT such that [sj = /; 

2. Compute 

3. Replace / by [aj; 

4. Replace g by 

5. Prove that [,sj — /; 

6. Prove that [.s'] - g ; 

7. Apply lemma (5) to prove that ([.s'] is the derivative of {«]. 

Steps 3 and 5 may seem superfluous, as a was constructed so that |,s] = / would hold. The problem 
lowever, is that we did not define this construction as an element of type (IR/tIR) VT (because no such 

ProPer : ,eS ™ S,S) ’ ~ anytliing i,, gc „L, ab„„, 

equalit J ^ ™ s,mplification on W >delds / and we just have to invoke reflexivity of 
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Step 6 is t hr trickv one. In the most cases, this will reduce to proving some inclusions of domains (which 
we have already automated) and then equality of two algebraic expressions (which the Rational tactic, 
described in [8]. can normally deal with); in some cases, however, this step leaves some work to be done, 
for example if the equality between [.s'J and g relies on the fact that any two derivatives of a given function 
must coincide. Even in this cases, however, experience has shown that the goal has been much simplified, so 

that we do profit from this tactic. . 

\ t the present moment, the biggest limitation of this tactic is that it cannot deal with division or 

functional composition. However, experience shows it to be much more efficient (both regarding computation 
time and the size of the constructed proof-terms) than the first approach. Also the limitations turn out not 
such a big problem as they could seem, actually, because we can always add the relevant steps as hypothesis 
to the context and prove them later; but they still are limitations, and it is interesting to see why we can t 
deal with these cases in the same way as we dealt with the others. 

When we look at the constructive rule for derivation of a division or composition of two functions, they 
turn out to differ from the other rules in that they have some side conditions that have to be met: as an 
example, to apply the rule for division, we have to prove that the absolute value of the denominator of the 
fraction we want to derive is always greater than some positive constant. In order to prove that this side 
conditions always hold (which we have to do if we want to prove something like V,.[.s'] = [*]')■ we have to add 
in the constructor of VT corresponding to division an argument stating something about the interpretation 
of one of the other arguments. But this is not possible in Coq, because we cannot simultaneously define an 
inductive type and a recursive function over that type (although type theory allows us to do this, namely in 


this situation). , 

The case of composition is even worse, as one of the goals we get says something about one function 

being the derivative of another in an unknown interval. One way to solve this problem would be to make 
our tactic interactive in some way. but there is no obvious way to do this. 

Presently, as we said, these limitations turn out not to be such a big deal. Division is not such an 
important operation when we work constructively, as most situations that use division can be rewritten so 
as to use only multiplication; and for composition we can usually achieve our goals by adding hypothesis to 
the context, and applying the chain rule by hand. When none of this works, we can still rewrite the function 
on the right-hand side of the goal with the first operator wc define and proceed by hand. 


5 Related Work 

This same fragment of real analysis has already been formalized in some systems by different people. We 
will now briefly describe these' formalizations and how they differ from ours. 

Micaela Mavero (see [11]) has formalized differential calculus in Coq, including notions of (point- wise) 
continuity and differentiability, derivation rules, and some work on transcendental functions. However, she 
does not treat integral calculus or more general theorems like Rolle’s theorem. This is because her motivation 
is not. formalizing real analysis in itself, but showing how such a formalization can be used for other purposes, 
whence she develops just the theory that she needs for her examples. For the same reason, she argues that 
it. makes more sense for her to work classically— which makes her work totally distinct from ours. 

Mayero’s treatment of partial functions also differs from ours. As we do. she always associates a domain 
with every function; however, they are kept completely separated: functions have type ]R IR, domains 
IR — > Prop, and the domain is always explicitly stated in the formulation of the lemmas. Although this 
makes it possible to write things down in a way closer to usual mathematical notation (that is. f(x) instead 
of f{x.H) or something similar) it does have the disadvantage that you can write down things like 
although it is not dear what they mean. 

In the PYS system, Bruno Dutertre (in [5]) has also developed a classical theory of real analysis, including 
the main definitions in differential calculus. Building upon this work. Hanne Gottliebsen built a library 
of transcendental functions described in [9], where she defines exponential, logarithmic and trigonometric 
functions, proving similar results to ours. She then defines an automatic procedure to prove continuity of a 
large class of functions, which works in a similar way to ours, and shows how it can be used interactively 
with Computer Algebra systems to guarantee the correctness of applications of the Fundamental Theorem 

of Calculus. 
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John Harrison’s HOL-light. system (described in [10]) is another proof assistant, that comes with a library 
of real analysis: once again, the reasoning in this system is classical. The results included in this library 
include the usual results on preservation of continuity through algebraic operations, derivation rules. Rollers 
theorem and the Mean Law. 

Also included in the system is a library of transcendental functions, where exponential and trigonometric 
functions are defined as power series and their inverses as inverse functions. Finally, integration is defined 
and the Fundamental Theorem of Calculus is proved. 

6 Conclusions and Future Work 


We have shown how to formalize an important fragment of constructive real analysis and how to use this 
formalization to build automation tools that can (partly) solve some problems in this area, by providing 
not only an answer but also a proof that this answer is correct . Presently we deal only with differentiation 
in a restricted class of functions, but work is being done to generalize the setting to all the elementary 
transcendental functions. We hope to complete this work with similar results regarding integration, namely 
by providing a wav to integrate rational functions and prove the result correct. 

In doing so, we have also shown that it is possibly to build and use modular libraries of mathematical 
formalizations, as our work was done using a library of real numbers which was already developed and to 
which no changes wen 1 made (although some results had to be added dealing with specific problems). We 
have also provided evidence to Bishop s claim that it is indeed possible to do useful mathematics without 
the double negation rule. 
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1 Introduction 
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1.1 Compositional development 
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axioms [10] to the germination of the idea in work by Floyd [9] and even Turing [29], By supporting the 
meaningful specification of open systems, the assumption/commitment approach has become the cornerstone 
or mam compositional approaches to treating complex systems. 

The adoption of what we term the assumption/commitment paradigm in the development of process 
networks may be traced to Misra and Chandy [20], who used assumption/commitment specifications on 
ccDn. traCeS t0 de o P 3 com P° sitional method for the verification of safety properties in networks of 
f ' ' e P r ° cesses - Subsequently, many other authors have used similar approaches to develop methods 
for the verification of v-arious subclasses of process properties. Some such approaches are due to Pandva 
and Joseph [-6]; Abadi and Lamport [1]; Stolen, Dederichs, and Weber [27]; and Stolen [28]. In everv case 
however, the methods offer complex verification conditions and (with the exception of that of Stolen) allow 
the treatment of at best a restricted class of process properties. Furthermore, thev relv for their effectiveness 
on specialised (and somewhat baroque) process models with narrow areas of application. The primary reason 

or such complexity and restrictions lies in the difficulty of defining a general, compositional model of network 
construction. 

One difficulty in modeling network construction has been the common approach of defining a parallel 
hookup operator which includes both parallelism and feedback capabilities. The complexity of such all- 
purpose operators tends to overwhelm the search for tractable approaches to reasoning. As observed bv 
Katis et al [12] it is preferable (at least in the abstract) to define separate parallel and feedback hookup 
operators. Another difficulty has come from the tendency to treat feedback in terms of recursive function 
theory. A more promising approach has been suggested by Katis et al [12]. They describe a relational feedback 
operator based directly on a naive notion of fixed points. As demonstrated in the remainder of this paper, 
making use of a separate feedback operator based directly on this naive notion of fixed points greatly improves 
the tractability of reasoning about networks of processes. 


1.2 Refinement 


A separate development of the assumption/commitment paradigm has seen the utilisation of predicate trans- 
former semantics in support of compositional development methods for sequential programs. Weakest pre- 
condition program semantics were first suggested by Dijkstra [8] and have been blended successfully with 
the assumption/commitment paradigm independently by Back [4], Morgan [21], Morris [23], and Nelson [24] 
Ihese formalisms have much in common and are referred to collectively as the refinement calculus. 

e refinement calculus is a broad-spectrum, specification/programming language together with a col- 
lection of refinement rules that support toj>down design. High level specifications are refined to mixtures 
of specification and program code and finally into pure program code. The pure code subset of the refine- 
ment calculus is called the implementation language and will vary with the problem to which the refinement 
calculus is being applied. For example, Morgan’s program refinement calculus adopts Dijkstra’s guarded 
commands as its implementation language. 

The refinement calculus approach has been used successfully in several case studies in the specification 
and design of real-time and reactive processes [13, 15, 17, 18], The purpose of this paper is to formally define 
an extension of Back s predicate-transformer model so as to allow its use in the treatment of interacting 
processes. By formally, in this case, we mean that the extension has been developed using a formal modelling 
tool, namely Isabelle’s HOL modelling environment [25], 

Following Katis et al we describe a network construction model which allows processes to be hooked up 
in sequence parallel, and via feedback. The sequence operator is well known, being originally described by 
ij -stra The parallel operator has been the subject of considerable interest in recent years, first defined bv 
Martin [19] and then investigated in detail by Back and Butler [5,6] and also Mahonv [14], The feedback 
operator is partially a contribution of this paper, having been suggested by the relational operator of Katis et 
aL Following the usual refinement calculus approach we define a collection of novel refinement laws involving 

these operators that support the top-down development of process networks from abstract specifications to 
concrete implementations. 

The resulting refinement environment represents a powerful tool for the analysis of both liveness and 
safety properties of dynamic proceses. Furthermore, it is a tool which does not depend for its effectiveness on 
a particular model of computation. In particular, it is in principle possible to adopt either digital or analog 
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Fig. 1. Example process network. 


nrocess models and even to mix them. This represents a clear advance in analytical completeness over the 
restrictive classes ol properties and systems treated by most of the methods de»Hbri * cle ” 

advance in tractability over the more complete, though still model-specific, method of Stolen [-8]. 


1.3 Summary of paper 

The balance of the paper has the following outline. In Section 2 the basics of predicate transformer algebra 
are introduced In Section 3 the three network hookup operators are defined and refinement rules introduced. 
In Section 4 an implementation language for networks of IFO machines is introduced. This language is use 
I; Section 5 to present some examples in the use of the refinement calculus Finally, the results of the paper 
are summarised in Section 6 and the network refinement calculus compared to existing net w or ' \en c 

methods. 


2 Predicate transformer basics 

This section briefly introduces the basics of predicate transformer algebra, as presented by Back and von 
Wright [31. The formal text in this paper follows the syntax and conventions of the Isabelle/Isar iniplementa- 
tion of HOL [25]. In particular, proofs are presented in the Isar style [30] of proo -programming, ne _ 
proof justifications fall into three broad categories. The keywords rule, intro and 

orems as inference rules. The keyword simp indicates the unwinding of definitions. The keywords auto, fast 
and hiTndicate the use of automated proof procedures. In general, the full Isar proof scrtpt is P = ted, 
but where the full proof is particularly tedious we elide it, offering instead a brief informal justificat ion. 

This paper aims to address the high- assurance design and analysis of complex processes. Processes a 
viewed as hierarchical networks of process elements communicating along dedicated channels ' J uc 
may be represented using annotated graphs such as that depicted in Fig. 1. \anous forms of poh gons are 
us«i to remient classes of network elements and directed arcs are used to represent information flows 
or process components. This ability to render process networks in a graphic form is an important tool foi 
ZZ^UngdKir component structure and mill form the basis of a graphical user !„«.*« , for 
with process hierarchies in a forthcomming version of the DOV E tool. We make judicious use of it throughout 

th, shaper. rties ^ esseg are expressed through predicates. The reader is assumed to be familar with 
the algebraic properties of predicates, but briefly a predicate is a boolean-valued function of process 

state I. The usual boolean operators are lifted to act on predicates, with the following operator precedents. 
A) Vi The standard boolean order is lifted pointwise to define the entailment order ( ) 

predicateSntify for describing pr0 cesses/specifications that, given inputs from I, construct 

The simplest model of process is as a logical function f::I -» F from input states I to output states f. 
Functions allow us to describe from each input precisely the desired output. Such detail is of course necess . 
for an implementation, but is often tiresome in the early stages of design. 
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An easier option is to specify a range of allowed results. This can be done using a relation R::I <-> r. 
which is a function from input states I and output states T to the booleans. The natural lifting of the 
boolean order to relations yields the entailment order on relations (also written ^>) which increases as more 
choices are added to a relation. The range of choices allowed by a relation is known as the nondeterminism 
exhibited by a relation. A relation S::JT <-» r , such that S ^ R, may be thought of as an implementation of 
FI. 

In the abstract, relational entailment offers a simple, and therefore attractive, model for treating the 
design process, but in practice relational verifications tend to be hard to deal with and to involve numerous 
repetitive and complex calculations. In addition, it can be difficult to treat incompleteness and inconsistency 
in specifications in an entirely satisfactory manner. These problems can be overcome by adopting the pred- 
icate transformer as the basic process model. Predicate transformers were introduced by Dijkstra [8] as a 
generalisation of relations. 

A predicate transformer p::I T is a function from predicates over output states 3 r , which we refer to 
as effects , to predicates over input states B~, which we refer to as presumptions. 


2.1 The refinement calculus 

Predicate transformers offer a richer algebraic structure in which to model and analyse computational mech- 
anisms, than do either functions or relations. Indeed Dijkstra seems to have found predicate transformers too 
rich in structure and immediately began suggesting “healthiness criteria” intended to restrict attention to 
those predicate transformers sufficiently relation-like in nature to be comprehended using his existing rela- 
tional intuitions. As our understanding of the algebra of predicate transformers has grown, we have gradually 
come to appreciate the power of such unintuitive features as magic, coercion, and angelic non-determinism, 
however one healthiness criteria remains. We make use only of those predicate transformers which are mono- 
tonic with respect to entailment, since these are rational in the sense that stronger presumptions are required 
to achieve stronger effects. 

In the following, we use the term process as a synonym for monotonic predicate transformer, since this 
makes it easier to convey the intuitions behind the predicate transformer model. 

defs monotonic-def : monotonic p = 

Though w’e do not present the proofs, all of the operators presented in this paper construct monotonic 
predicate transformers. 

The pointwise lifting of the entailment ordering is called refinement (_ C _) and is read “is refined by”, 
defs refbyeq.def ; pEq = V0*p<£^>q0 

The term refinement alludes to a view’ of top-dow r n design as the process of removing the “impurities” 
of incompleteness and nondeterminism in a specification until all that is left is the “pure” code which was 
original!}’ intended. This view is supported perfectly by the refinement relation since every refinement of 
a process is able to achieve all of its effects under the same or weaker presumptions. Thus from a process 
design standpoint, it is always acceptable to replace a process with a more refined process. 

Much of process design can be view’ed in terms of finding solutions to problems in process refinement 
and the algebra of predicate transformers provides an ideal tool (we call it the refinement calculus) for 
actually calculating solutions to design problems. This calculational facility often allows predicate transformer 
based verification systems to be simpler than corresponding relational systems. In the refinement calculus, 
verification laws tend to require few’er human-supplied parameters (many parameters can be replaced by 
calculated most-general solutions) and few’er verification conditions (most-general solutions are solutions by 
construction). In fact, these law’s tend to be so much simpler that w r e call them refinement laws, so as to 
focus attention on their use as design development tools rather than design checking tools. 

The approach to network design taken in this paper involves the definition of a collection of pred- 
icate-transformer operators that allow’ the modeling of process designs and implementations, together with 
refinement laws for introducing and eliminating these operators during design development . 

Again, though the proofs are not presented, all of the operators presented in this paper are monotonic 
with respect to the refinement relation. This property is called vertical compositionality by Zwiers et al [31]. 
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(b) coercion 



(c) function (d) specification 


Fig. 2. Predicate transformer embeddings. 


InZZ horizontal compositional.* is a function of ‘ he 

All refinement calculus operators must be mono»«». ■ b “* ^,“?Xfvle"S emphasises the transformation 
For example. we write 

— — G 


for the proposition G => p Q Q- 


2.2 Predicate transformer embeddings 

s“^m^ 

on a network graph, as depicted in Fig. 2(a) and 2(b). 

defs 

assert ^def: {A} = A</> • A A (f> 
coerce-def : [A] = A<t> • A => <fi 

Assertions are refined by weakening their predicate and coercions by strengthening it. 


lemma assert W 


m 


d> ^ ifr 


by (simp add: pand.def) 
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lemma coerceS: 


m 


w 


>t> s <!/ 


by (simp add : pimp.def ) 

Simple functions become point-replacement operators when embedded as predicate transformers. They 
are represented on network graphs as diamond shaped nodes, see Fig. 2(c). 

defs function.def : </> = A<f> a«0 (fa) 

Relations may be embedded as predicate transformers to give abstract specifications of desired relations 
between inputs and outputs. Following Morgan [21], we introduce the specification statement as the pri- 
mary method of expressing relational specifications. In addition to a relation between inputs and outputs 
(the commitment), the specification statement also includes an assumption about the properties of inputs 
Specification statements are represented graphically by rectangular nodes, partitioned into assumption and 
commitment compartments, as shown in Fig. 2(d). 

defs spec-def: [A/E] = A</> a • A a A (V b# E a b => # b) 

The main refinement laws dealing with specification statements allow the utilisation of the assumption 
when strengthening the commitment and the weakening of the assumption. 

[A/E,] 


lemma commit. S: 
by (auto) 

lemma assumeW 
by (simp) 


l A/E 2 ] 

[A,/E] 

[A 2 /E] 


(da b • A a A E 2 a b) ^ E\ 


A deterministic specification is refined by the corresponding function. 
[A / Aa b* b - f a] 


lemma funl : 
by (simp) 


</> 


3 Network constructors 

We support three methods for hooking up the inputs and outputs of processes, as shown in Fig. 3. The 
first method is sequential hookup, which is modeled by function composition. The second is parallel hookup 
which is modeled by the predicate transformer product operator. The third is feedback hookup which is 
essentially coerces one of a process’s outputs to have the same value as one of its inputs 


3.1 Sequential hookup 

Composing processes sequentially is a simple matter of passing the outputs of one to the inputs of the second 
In the functional model this is achieved through function composition, in the relational through relational 
join, and in the predicate transformer through reverse function composition. Sequential hookup is monotonic 
associative, and its identity hookup is the identity function 1. 

defs 

fseq.de f: f»g = Aa»g (fa) 

rseq.def : R » S = ,1a b»(3c» R a c A Sc b) 

seq.def: p » q = ,1 <t>»p (q <p) 
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(a) sequence 


(b) parallel ( c ) feedback 

Fig. 3. Hookup mechanisms. 


The technique for sequential decomposition of a specification, is to first express the commitment as a 
sequential composition. 

[ A/E » F] 

lemma midi: [A/E ] » [,!!>• 3 a«A a A £a b/F] 

by (auto) 


We also require rules for introducing coercions 
fications. 

lemma coerce I: ~ 

[<t > ] » P 

by (simp add : pimp.def) 

[0] » [A/E] 


and for transferring information from coercions to speci- 


lemma assumeS: ^ A A/E] 

by (simp add: pimp.def pand.def ) 


3.2 Parallel hookup 

SMS 

product operator. 

defs fprod.def: f i x f 2 = j , a 2 )*(fi ai. I: a 2 ) 

It is eauallv straightforward to define product operators for predicates and relations. However, lifting the 
notion to predicate transformers proved more difficult and a number of approach® M were pro^^ 
f e fnnnri Thp basic idea of this predic ate- transformer product is quite straightforward, tnat 
ITeffS predicates OTer a product space^o presumption predict, by mapping the individual = nts 

r^fs^ 

“,rt“ - — - - — 

"‘rectangles” contained in 0. 

defs product.def : p, x p 2 = M* V * 1 *2l*i x ^ ^ x ( P^ ^ 
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Fig. 4. Introducing a feedback loop. 


Tins definition was first proposed by Martin [19] and has been analysed in some detail bv Back and 
Butler [5, 6]. Another possible approach to defining a product is to make use of a relational decomposition 

property [19] to lift the relational product operator [14]. It turns out that both approaches yield the same 
operator. 

The basic technique for introducing a parallel hookup is to decompose the assumptions and the commit- 
ments according to the desired subcomponents. 

, , [A x B/Ex F 1 

lemma spec.prod: — — : i 

([A/ £]) x ([B/F]) 
by {auto simp add: pprod-def) 


Since, as already conceded, few predicates (or relations) are of rectangular form, this is a highly restrictive 
approach to introducing products. However there are some points that can be made in favour of this situation. 

rimarily, it must be noted that there should be no great imperative to decompose processes in parallel at 
an early stage of design. In fact, in the general case, this is likely to be a highly ambitious aim. Consider what 
such a decomposition implies about a design, namely that the subcomponents of a given process admit such 
a strong decoupling of their behaviour that their further development may be done in complete isolation. 
Seen in tMs light it is clear that the introduction of products should not be forced, but rather that products 
should be allowed to arise naturally from the design process as the elements of the design become more 
concrete and determined. Indeed, some process components may exhibit such strong coupling of behaviour 
that it never becomes convenient to explicitly separate them. 

An artificial imperative to perform such decompositions has been introduced into a number of existing 
approaches due to the coupling of the product and the feedback operators. In order to make use of the 
properties of a feedback loop in a design it is thus necessary to “discover” a suitable decomposition of the 
process components This forms a major barrier to the use of such methods and is a strong argument in 
favour of a decoupled approach to modeling parallel processes. 


3.3 Feedback hookup 

The third method of hooking up the inputs and outputs of processes is through the introduction of feedback. 
The essence of feedback, as it is for iteration and recursion, is the construction of a fixed point. To see this 
consider the simple (abstract) network element depicted in Fig. 4. The effect of introducing a feedback loop 
(depicted as a dashed line) from the output y to the input x is to equate their two values, necessitating the 
discovery of a fixed point of the process when viewed as an input/output transformer. The only difference 
is that in the cases of iteration and recursion the desired fixed point is a program while in the feedback 
case the desired fixed point is some user-defined data structure. This of course has profound implications 
or modeling feedback since it cannot be treated straightforwardly through the existing, complex models for 
treating iteration and recursion. Perhaps the very focus on highly-developed fixed-point theories for treating 
l eration and recursion has been something of a distraction in the treatment of feedback (we discuss other 
approaches m Sect 6). In fact, as was pointed out clearly by Katis et al [12], the situation with feedback is 
actually much simpler. The introduction of a feedback loop may be viewed quite simply as the strengthening 
of an existing specification to require that an output have the same value as a given input. It is this model 
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Fig. 5. Definition of feedback. 


of feedback which we adopt, embodying it in the predicate transformer model by (as depicted in Fig. 5) 
introducing the appropriate coercion and hiding the feedback variable so as to protect it from outside effects. 


x' = x) x true ]) (true x <t>) (x, a)) 


defs feedback-def : 

(p) <t> a = (Vx • (p» l(d x' 

Since a feedback loop introduces a hidden coercion, it is important to have a clear intuition as to the 
potential effSts this mav have. The first and most obvious danger is that the component process may have 
no fixed points making the feedback process inconsistent and therefore unimplementable. A more subtle 
danger is^that^ he component process may have many fixed points, even if it is itself deterministic. Thus a 
feedback process mav be nondeterministic even if its component process is deterministic. 

Introducing a feedback loop is simply a matter of expanding the input/output spaces of a speci ca ion 

to accommodate the feedback component. 

[A/E] 

lemma specJbl: f M(x , a) . A a / .fix, h) (a". b')-E b b']] ~ 

by (simp) 

After applying spec.fbl the designer is free to use other refinement laws to introduce the desired prop- 
erties of the ? feedback component. The important question in this is how the designer should go abo 
introducing assumptions about the behaviour of the feedback component. Our suggested approach harks 
back to Morgan’s [21] original arguments in favour of the positive applications of mirac es. e propo 
the^iesigner^hitroduce the desired properties as coercions of the feedback component on the input side so 
as to allow them to be used as assumptions in subsequent development. Such refinements would conform to 

the following general outline. 

have 

[A/E] 

c 

[ [ /l(x::o\ a) • A a / /l(x::a, b) (x\ b>E b b']3 
by ( rule spec^fbl [ ruleJormat 1) 
also have . . . 
c 

[ [F] ([ /l(x::a, a)* A a//l(x::a, b) (x\ b r )^E b b'])3 

by (intro monotonic-operators, rule coercel) 
also have . . . 
c 

[[F]»[Fa (d(x::a, a)* A a) / A(x::a, b) (x\ b>Ebb']] 
by (rule monotonic-operators , rule assumeS) 

This stvle of development turns out to be a safe application of miracles because the fixed point P ro P ertle ® 
of the feedback components mean that these coercions can eventually be eliminated using the folio g 

refinement rule. 

[[El »<f>] 


lemma fb.coerceE : 
by (auto) 


[</>] 


Vx a#fst (1 (x, a)) = x => E (x, a) 
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Thus, once the dataflow element has been refined to an implementation (function), any coercions on the 
feedback components as inputs that have been used to aid that development can be eliminated, provided 
they are in fact established on the feedback components as outputs. 


4 Input/output machines with feedback 

The astute reader will have noted (perhaps with some annoyance) that we have not yet mentioned any 
concrete model of process behaviour which would legitimately allow us to consider the above formalism a 
refinement calculus for process networks. The paper has been so presented in order to stress the fact that 
all of the refinement calculus mechanisms of network composition are independent of the concrete process 
model to be adopted. Thus we are free to fit the refinement calculus approach onto virtually any (state-based) 
process model which supports any or all of the sequential, parallel and feedback forms of hookup. 

Of course, in order to present any interesting examples in the use of the refinement calculus, it is necessarv 
to choose a particular concrete process behaviour model. The first decision in choosing a model is determining 
how best to represent observations of the system components and an important part of this is deciding on an 
appropriate model for time. In the large informal case studies we have done in network refinement we have 
generally been concerned with physical flows such as water levels and line voltages [13, 15, 17, 18] and have 
made use of the real numbers to model time. Unfortunately real-analysis support in Isabelle is not really 
mature enough to be used for giving the sort of simple examples in refinement that we wish to present here. 
Instead we model system observables using the natural numbers as our model of time. 

Another important decision concerning such a model is the selection of a class of specifications which 
may be considered terminal points of the design process, that is to say the process implementations. In the 
program refinement calculus the assignment statements (deterministic, total specifications) are used as the 
basis of the implementation language, the general class of implementations then being the closure of the 
assignments under the various program operators. The introduction of the feedback operator complicates 
this approach by having the potential to introduce non-determinism and even magic, even when applied to 
deterministic processes. We must be careful how feedback is used in the implementation language if we are 
to ensure the functionality of all implementations. Of course, a comparable problem also exists in the case 
of the while operator, the difference being that a while statement may introduce incompleteness rather than 
nondeterminism or inconsistency. Our approach to treating this problem is to construct an implementation 
language in such a way as to ensure that feedback loops do not introduce nondeterminism or inconsistency. 
An alternative approach might have been to follow the lead of the while-loop and introduce notions of 
partial-correctness (all fixed points are refinements) and total-correctness (there is exactly one fixed-point). 

The rest of this section is devoted to presenting a simple model of multi-threaded computation based 
on digital traces and an implementation language which we call IFO machines, input/output machines with 
feedback. 


4.1 Traces 

Temporal observations of I/O machines are modeled by traces. The simple traces are functions from the 
natural numbers to instantaneous observations of the inputs or outputs of the I/O machine. We write E* for 
the simple traces over E . More complex traces are built up as tuples of simple traces. We find it convenient 
to adopt a subscript notation for indexing of trace elements, for example writing f„ for the n ,h element of 
the trace t. 

Complex traces are composed/decomposed using the tzip/tunzip functions, 
defs 

tzip.def: tzip = At • (An • ((fist t) n , (snd t) a )) 
tunzip_def: tunzip = At* (An *fst t„. An * snd t n ) 

Values may be attached to the front of simple traces. 
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defs tcons-def : a#f = • if n = 0 then a else t n _ j fi 

An indexed collection of predicat.es/relations can be lifted to a trace predicate/relation by conjoining 
their pointwise applications, 
defs dpprod-def: 7! <P = -U • V 21 • ( P n bj 

In theory, the distributed product operator offers the power to express any desired predicate/ relation 
over traces. This is because every trace t has a corresponding characteristic predicate * t which identifies 
exactly the given trace. The characteristic predicate of a trace may be expressed as the distributed product 
of the trace’s elements 

X t = Tin • As • s = t„ 

and hence any predicate/relation may be characterised as a disjunction of distributed products. 

<p = Vt \<j> t •x t 

For the purposes of this paper this theoretical completeness is sufficient, but it should be noted that in 
practice some form of sophisticated temporal logic would be convenient for expressing and reasoning about 

the properties of traces. , 

Trace predicates that may be expressed as distributed products or finite disjunctions of distributed 

products are what Alpern and Schneider [2] refer to as safety properties. These are characterised formally 
as: those predicates for which, any trace excluded by the predicate has a finite prefix, that has no extensions 
that satisfy the predicate. The dual notion of liveness is also introduced, a liveness property being one for 
which, even- finite trace has an extension that satisfies the predicate. Informally, safety properties may be 
violated in a finite time, while liveness properties may not. These notions of safety and liveness have taken 
a central role in the search for tractable reasoning systems for distributed networks. A special form of safety 
property is the invariant which may be expressed as the distributed product of a constant function, that is 
in the form (77n*7) for some instantaneous predicate I. 


4.2 IFO machine constructors 

The basis of the IFO machine language is the I/O dynamic, which consists of a predicate transformer 
of instantaneous states applied pointwise to an entire trace. In order to define this notion of pointv ise 
application, the distributed product operator is lifted to processes in much the same way that the binary 
product was lifted. 

defs 

dfprod-def: 71 f = At n«f n t n 

drprod.def : 77 R = At s • (V n • R n t n s n ) 

dprod.def: 77 p = A4>m(\f <P\{71n*<P n ) <t> • (77n • p n <P n )) 

The distributed product operator builds processes which calculate output traces by iteratively apph ing 
sequential programs pointwise to their input traces. Actually the distributed product operator is somewhat 
too general to be considered a real process operator, since it allows the sequential programs to vary with time. 
In order to realise this a process would need to have some innate sense of absolute time, where in act uality 
processes are only able to gauge t he passage of time through the explicit use of devices such as clocks and 
counters. In light of this observation, we introduce a restricted form of distributed product (do.od) in which 
the iterating program may not vary with the passage of time. This operator we call the dynamic program, 
or the do-loop, and presented in graphical form as an oval shaped network element as shown m Fig. 6(a). 

defs dvnamic-def : do p od = 17 n* p 

While a complete approach to developing process networks would require the adoption of a particular 
sequential programing language for expressing dynamic programs, for the purposes of this paper it is adequate 
to abstract away from such details. 

The basic introduction rule for dynamics allows a trace specification involving an invariant assumption 
and an invariant effect to be refined to a dynamic specification. 
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(a) dynamic (b) latch 

Fig. 6. 10 process elements. 

[ Fin* A / I7n» E] 

lemma spec.dvnl : 

do [ A / E] od 

proof {simp) 

It is sufficient to observe that every trace property achieved by an invariant effect is satisfied by achieving 
the effect at every point in the trace. 

fix 0 a assume al : V n::N • A a n and a2: V b • (V n::N • E a n b n ) => & b 
show 3 <P • ( V b • (V n::N • <P n b n ) =» <p b) A (V n b • E a n b <P n b) 

by (simp add: a2) 

qed 

For the most part the observations we made in regard of the strong decoupling required by the product 
introduction rule apply again to this rule. An interesting point in this case is the fact that the decoupling 
appears to restrict us to the treatment of invariant properties. In fact, the restriction merely introduces a 
requirement to refine the trace specification by weakening assumptions and strengthening effects to the point 
where it is expressed by some invariant behaviour. Arbitrary trace properties may be freely used at any point 
up to the introduction of a dynamic design. The restriction at this point is not artificial, but rather a natural 
result of adopting the dynamic as the basic computational device. Of necessity, a dynamic can only effect 
behaviour that can be achieved by repeatedly performing the same (invariant) task. Nor is the choice of 
the dynamic particularly unfortunate or artificial, the majority of embedded, control and communications 
applications adopt exactly this architecture of tightly scheduled repetitive behaviour. 

The main advantage in adopting dynamics as the basis for a network implementation language is the 
observation that deterministic dynamic processes are causal We don’t attempt to define this notion in the 
general case, but in the deterministic case a causal process is one for which the first n inputs uniquely 
determine the first n outputs. That is, the process does not look forward in time when determining the 
current output. Clearly this is a necessary requirement for any notion of process implementation. 

Any process constructed from causal network elements using sequential and parallel hookup will also 
be causal, but, unfortunately, causality is not necessarily preserved under feedback, nor is it sufficient to 
preserve determinism under feedback. In order to preserve causality and determinism, we follow Stolen [28] 
and introduce the stronger notion of guardedness. A (deterministic) process is guarded if and only if the 
(n+i) th output is uniquely determined by the first n inputs. For a detailed discussion of guarded trace 
functions the reader is directed to Stolen [28]. 

The guardedness of a process may be ensured by introducing a delay' or latch element into the network. 
Latches are depicted in network graphs as small triangles, as shown in Fig. 6(b). 

defs latch-def: a> = (dt«a#t) 

A feedback loop is causal if the enclosed (causal) process is guarded in the feedback component. This 
may be ensured by restricting feedback loops to be of the form 

[ p » (a >) x 1 ) 

where p is a causal process. We call such feedback loops guarded-feedback loops and write 

[a<— p] 

as shorthand for the above process. 
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Fig. 7. Elided network connectives. 


In addition to dynamics and latches, the causal processes 1, <izip> and (tnnz/p) are u*ful neuvork 
connectives We introduce abbreviations ® and ® for the processes <tztp) and (runzip) respectively. We 
not explicitly represent these processes on network graphs, since it is straightforward to infei then preaenc 
"nHE™ in which explicit network elements are connected. For example, since a dynamic must have a 
Imgie input stream and a product must be between processes, if can he inferred that the diagram of Fig. , 

refers to the process 

((9) :$> do pod) X 1. 


We are now in a position to define the IFO network language. 

- A dynamic machine do<f}od is an IFO machine for any function f. 

- The processes 1, © and © are IFO machines. 

- If p and q are IFO machines then so are p » q and p x q. 

- If p is an IFO machine then so is C a < — pi. 


In the case that p is of the form 


©;» do(g)od» © 


it is straightforward 
uniquely constructs 


to show that 


C a < — p 1 

the feedback t race x which satisfies the recursive equations 


x 0 - a 

(X n +j, tn) — g( x n • s n). n € I I 


where s and t are respectively the global input and output. Thus, guarded feedbacks ensure the preservation 
of both determinism and causality and all IFO machines are both deterministic and causal. 


5 Some simple examples 

In this section we present example refinements which illustrate the basic application of the network refinement 
calculus. 


5.1 Accumulating a sum 

We begin with a straightforward, but thorough exercising of the refinement calculus approach. In order 
to improve the readability of the example, we elide lambda bindings representing state vana tb es i inde^he 
convention that the names of the state variables and the context identify the formal arguments to the lambda 
ZrttTon For example, given state variables x and y, we would write x = y for the relational abstraction 

lX simple' network application is to calculate a running sum of the values being passed along input s, 
passing the results on output t. This may be expressed very straightforwardly as a relational specification. 
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+ 


Fig. 8. The summing machine. 

let ?SUM = (Vn.t n = I£ = 0 s*) 

A simple solution to this problem is to use a feedback component a to store the previous value of the 
sum. The relationship between a and s is: 

let 7PSUM = a 0 = 0 A (V n • a n+1 = = o s k ) 

The desired property of t can then be effected by adding a to s at each cycle as shown in Fig. 8. 

The refinement argument begins by introducing the feedback component. 

have [ true / ?SUM] 
c 

[ [ true / ?SUM] ] 
by (rule spec.fbl ) 

Next we focus on the design of the internal component, first coercing the feedback property on the input 
side. 

have [ true / ?SUM] 

c 

[7PSUM] » ([ 7PSUM/ 7SUM]) 
proof —apply coercel and assumeS qed 

Now we focus on refining the specification statement, requiring first that b be a latched copy of t and 
that t be the sum of a and s at each point. 

have [ 7PSUM / 7SUM] 

c 

[ 7PSUM / b = (OH) A (V 12 • t n = a n + s n )] 
proof ( rule commits IruleJormat]) 

The entailment is easily demonstrated by induction. 

qed 

The next step is to decompose the commitment relation, introducing relational sequencing and product, 
then lifting these to the process level. 

also have ... 

£ 

[ 7PSUM / 

(b = t A (V n • t n = a n + s n )) 

» ((b = 0#a) x (t = s))] 

(is _ c [ _ / 7SELT » » ]) 
by (rule commits [ ruleJormat ], auto) 
also have ... 


[ 7PSUM / 7SELT] (( 0» x 1) 
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proof - apply inidl and spec -prod qed 

Focusing on the summing element, we begin by eliminating the assumption. 

have [ ?PSUM / ?SELT] 

c 

[ true / ?SELT] 

by (rule assumeW [rule -form at], auto) 

Since boil, b end t depend on both a and a, we tip then, up to allow a dynamic implementation to use 
them both. We write as for the zipping of a and s and bt for the zipping of b an t. 

also have ... 

c 

© » [true/ ?SELT ( tunzip as) (turnip bt)] » © 
by (rule specjzipl) 

Focusing on the dynamic element, we re-express the commitment as an relational invariant, so as to 
implement it as a dynamic. 

have [true / 7SELT ( tunzip as) (tunzip bt)] 

□ 

[ true / 77 n • (b = a + s A t = a + s) ] 
proof - apply commits qed 

also have ... 

c 

do ((a', t) := (a + s, a + s))od 
proof -apply spec-dvnl qed 

Thus, we have shown that the design of Fig. 8 achieves the required commitment, provided that the 
feedback component properly stores the partial sums. 

finally have [true / ?SUM] 

c 

([?PSUM\ do((a\ t) := (a+s, a+s)>od » ©) » ((0>) x • 

The final step is then to eliminate the feedback input coercion, by demonstrating that the feedback 
component does store the partial sums. 

also have ... 

c 

[0< — © » do ((a', t) := (a+s, a+s))od » © 3 

proof - convert body to single function, then apply fb-CoerceE qed 

Thus we are now left with a pure IFO implementation of the summing machine specification. 

finally have [ true / (V n • t n = = o s k) 1 

c 

C0< — © do ((a', t) := (a+s, a+s)> od » ® 3 • 


5.2 The magic of refinement 

Our second example examines the potential dangers involved in introducing feedback assumptions and also 
the nrotections built in to the refinement approach. 

The main fear with making use of feedback assumptions is the possibility that the assumptions may 
become self-fulfilling prophecies. Since an implementation need only achieve its commitment w ien l s inp 
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satisfy the necessary assumptions, might it not be possible to use the postulated feedback assumptions to 
construct an implementation which achieves its commitment only because it has been assumed to do so? 
For example, consider the following refinement sequence. 

have [ true /As t • A s r ] 
c 

[ [A(x, s) • A s x] » [ A(x, s) • A s x/A(x, s ) (x\ t) • A s x A A s t]) 
proof —apply spec-fbl . coerceL assumeS. and commits qed 

At this point m the design process we have set up a potentially dangerous situation. Since x is already 
assumed to satisfy the required property A s x, we can get a refinement of the specification statement bv 
simply copying the input x across to the outputs x' and t. 

also have ... 
c 


[[Mx, s)^A s x] »<,I(x f s)#(A% X))} 
proof -apply commits \ then funl qed 


The design process seems to have gone completely wrong! It is clear that any further development from 
this point could not possibly result in an implementation of the original specification, but what could have 
gone wrong? We have carefully made use of trusted refinement laws and what we have arrived at is a design 
which we know cannot achieve the desired result. Is there a problem with the definition of feedback, or worse 
still a problem with the notion of refinement? 

Neither of these. What has happened is that we have made a bad design choice, a choice which has led 
us to a complete dead end. It is not just that we can no longer get to an implementation that satisfies the 
specification, it is no longer possible to get to any implementation at all. In order to get code from the above 
design we must, eliminate the input coercion and this we can no longer do. This coercion is our protection 
against making incorrect use of the feedback assumptions it allows us to introduce. It can only be removed 
when we have been able to establish the required effect on the outputs absolutely and without recourse 
to any feedback assumptions. This is not a unique phenomena in the refinement calculus, there are many 
situations where we are allowed the freedom to introduce designs that have no implementation. The basic 
argument in favour of risking such unsafe decisions is that the work required to ensure a design decision is 
safe is comparable to the work required to construct an implementation. In most cases, it is far better to 
risk the occasional deadend refinement sequence, than to be continually put to the work of checking that 
every design decision is safe. ^ 

That said, there are situations in which this is not the case, primarily in the development of large- 
scale projects in which multiple developers and indeed teams of developers are involved. Postponing the 
elimination of the input coercion until the final stage of design becomes a considerable risk when there are 
numbers of developers responsible for the various subcomponents of a system. In such cases it is imperative 
to have a method of eliminating the coercion before the commencement of separate development efforts on 
subcomponents. Fortunately it is possible to introduce variants on specJbl and fb.coerceE which support a 
more localised approach to dealing with feedback assumptions. 


lemma specJhh: 
by (simp) 


[A/E] 

A(X , a) • A a / A(x, a) (x\ b) • E a b ] ) 


lemma fb_coerceE2i 

\A] » [[4»[fca)*Aa/Fll 

C U(a\ a)* A a/F ]] 
by (simp, blast ) 


(A(x, s) • A s A (3 t • F (x, s) (x t t))> ==$■ E 


The important aspect of the variant feedback introduction rule spec-fbF is that the environment as- 
sumption is retained external to the feedback loop. The variant coercion elimination rule fb^coerceE 2 then 
makes use of this external assertion to allow the input coercion to be eliminated once the designer has fin- 
ished making use of it in the design of the feedback component. Thus the coercion is eliminated at a more 
appropriate time, prior to the commencement of subcomponent development efforts. 
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b. 


c 


Fig. 9. Using separate calculating units. 


5.3 A liveness example 

Our final example explores the use of liveness properties as feedback assumptions. Even though the refinement 
X^ttXingW assumptions do no, distinguish between liveness and safety, the importance 
this distinction has plaved in previous formalisms seems to demand that some attention be paid to t 
matter. However, we do" feel justified in only considering a simple and somewhat contrived example o 

4 stream processing machine accepts intermittent communications of natural numbers on a channel a,. 
For eal communication on channel a, it must calculate the value f, (f 2 and output it on channel b, 

Since ^lc”g the functions f , and f, may take a number of cycles, we simply require that for every 
— “n on a, there is eventually a response on b,. A similar requirement is placed on a second 
channel a 2 , with the exceptions that the processing functions are applied in the opposite ordei and that 

outputs am placed ^ requirements, 6 vw” model the notion of an intermittent channel as a trace over the 

in iorma-iibiug tuc M 5 m \ Tlync a trace of an intermittent channel consists 

natural numbers extended with a null element J. (N x ). thus a trace oi an mienmucm 

of natural numbers intermixed with null communications. We write 6a n for the ^eventual 

communication on the intermittent channel a is a proper communication. Formally, we express 

calculation of some function f by the following specification. 


let 7CALC f = d(a::(Nx)*) (b::(N L Y)* 

(V n • <5a n => (3 m • n < m A b m - f a n )) 

The requirement on b| is then 

7CALC (f i o f 2 ) aj bj 


and that on b 2 is 


7CALC' (f 2 o ft) a 2 b 2 . 


Both these requirements are liveness properties, because they do not dictate a deadline for when the calcu- 
faHons musll finished. Of course, it is not really intended that arbitrarily long times be allowed far the 
calculations. Rather this is a convenient way of leaving the determination of the calculation times until 
in the design process, when more is known about the mechanics of the calculations. , 

The symmetry of the problem suggests the possibility of decomposing the process into one element 
calculating Tand one for calculating?,. The idea would be to send inputs on a, directly to the f 2 processing 
element, then to the f , processing element and vice versa for inputs on a 2 . The resulting process topology 


depicted in Fig. 9. . 

The first step is then to introduce feedback components tor passing 

between the two processing elements. We retain the original assumption, so 
of the feedback coercion as described in the previous section. 


these intermediate calculations 
as to allow the early elimination 
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have [ true / :’CALC (f , o f 2 ) bj A 7CALC (f 2 of,)a : b 2 ] 
c 

{true} 

[[true/ 7CALC (f, o f 2 ) a , b, A ?CALC (f 2 o f,) a 2 b 2 ]f 
proof - apply spec.fbh qed 

The strategy for using these intermediate channels is to perform f 2 processing on messages from a,, then 
pass them along c, for f, processing before outputing them on b,. Similarly c 2 is used for intermediate 
calculations of messages on the a 2 channel. 

This strategy is implemented by introducing the intended properties of the intermediate channels as 
feedback assumptions, then using these properties to show that the proposed behaviour of the output channels 
satisfies the original requirements. 

also have . . . 

c 

{true} » 

C [?CALCf 2 a, d A 7CALCf l a 2 c 2 ] » 

[ 7CALC f 2 a, cq A 7CALC f , a 2 c 2 / 

7CALC (f , o f 2 ) ai b, A 7CALC (f 2 ° fi) a 2 ] } 
proof -apply coercel and assumeS qed 
also have . . . 
c 

(true} 

C [7CALCf 2 ai d A 7CALC f, a 2 c 2 ] » 

[ 7CALC f 2 aj c, A 7CALC f { a 2 c 2 / 

7CALC f 2 a, d ' A 7CALC f\ a 2 c 2 ' A 
7CALC f\ c, b] a 7CALC f 2 c 2 b 2 ]) 
proof ( intro monotonic.operators , ruie commits [rule_/ormat]) 

Eventually calculating one function and then eventually calculating the other is equivalent to eventually 
calculating the composition of the two functions. 

qed 

The last step in this design is to remove the feedback coercions that we have now finished making use of. 

also have . . . 

c 

{true} 

[[7CALC f 2 a, c, A 7CALC f { a 2 c 2 ] » 

[ true / 

7CALC f 2 ai c, ' A 7CALC f ] a 2 c 2 ' a 
7CALCf{ c\ b\ a 7CALC f 2 c 2 b 2 J] 
by (intro monotonic^operators , rule assume W [ ruleJormat ], auto) 

also have . . . 

c 

C [ true / 

7CALC f 2 a, ci ' A 7CALC f { a 2 c 2 f A 
7CALC f i d b, a 7CALC f 2 c 2 b 2 ] ) 
by (ruie fb_coerceE 2 [ ruleJormat ], auto) 
also have . . . 
c 

C [ true / 

7CALC f 2 a, d'A 7CALC f, a 2 c, 7 A 
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7CALC f i c i bi A 7CALC f 2 c 2 b 2 ]) 
by (intro monotonic .operators, rule assumeW [rule-format], auto ) 

The next step in the development would be to decompose the internal specification in parallel, but vve 
leave that as an exercise for the interested reader. The purpose of this sect .on was to ‘ l ™strate Ure 
liveness properties as feedback assumptions, in this case the properties . CALC f 2 a, c, and . C. » - -• 

The result has been a fairly banal repetition of our previous treatments of feedback assumptions. Indeed, the 
most novel aspect of the design derivation was the utilisation of the “localised elimination rule fb.coerce 2 
that was introduced in Sect. 5.2. This is not surprising, since the introduction rules for feedback coercions 
make no distinction between liveness and safety properties. 


6 Conclusions 

This paper has considered the application of the refinement calculus to the specification and desigr i of 
process networks consisting of sequential, parallel and feedback elements. The sequential and parallel hookup 
operators are well known from the literature [3, 5], but to the best of our knowledge the predicate transformer 
feedback operator is a novel generalisation of the relational operator proposed bj Ixatis et al\ -J. 

In order to make use of feedback assumptions in process developments, we have suggested the novel use 
of coercions on the feedback components as inputs. We have shown how these magical annotations maj be 
eliminated from the final implementation (f b.coerceE ) or even from earlier stages of the design m ie case o 
large-scale developments (fb.coerceE 2 ). The addition of these refinement laws makes the refinement calcu us 
a powerful tool for analysing process networks, capable of treating both safety and lneness proper i 

^An^ important aspect of the resulting network refinement-calculus is its abstraction from any underlying 
model of process computation. The network refinement-calculus is potentially able to support a wide range 

of implementation models either in isolation or even in combination. , . 

As a means of providing concrete examples of the network refinement-calculus in action we have intro- 
duced the IFO machine as a simple, abstract model of process computation. The basic building block of 
WO language is the dynamic , a novel, if straightforward, generalisation of the product operator. Specialised 
refinement rules have been introduced to support IFO implementations and some examples given in the 
refinement of IFO machines. Again we stress that the refinement calculus is not restricted in its applicat ion 
to these IFO machines. It could just as easily have been applied to dataflow/stream-processing functions, 
real-time automaton, state machines, or indeed any state-based model of process computation. Applying the 
network refinement-calculus to event-based models may be more problematic since they sometimes lack a 

clear distinction between input and output components. , , r 

It is worth noting here that the various hookup introduction rules make no distinction between the use of 
safety and liveness properties, either in assumptions or in commitments. In fact vve had no need of introducing 
the notions at all until vve came to the introduction rule for IFO dynamics. The treatment of liyeness has 
°enerallv been a problematic aspect of network design formalisms. Misra and Chandy [ 0] restricted their 
approach entirely to safety properties, while Lamport’s TLA [1] finesses the problem by intr^ucing t^ 
arcane notion of the closure of a liveness property to overcome a prohibition on the use of liveness propel 
as feedback assumptions. More recently, Stolen has proposed a feedback verification rule 'vhich afimvs the 
use of liveness properties, but once again it involves the difficult computation of closures and in addit on 
the introduction of an invariant property (with a safety component). All of these difficulties stem from t 
treatment of feedback through the sophisticated notion of recursion, rather than through * ^naUevel 

notion of fixed-point. Although at the function level, these notions are almost identical, at the relational le^ 
they differ vastly. A recursion-based view of feedback immediately places the focus on finite traces and sa e v 
forcing an indirect treatment of infinite traces and hence liveness. By adopting the naive fixed-point approaci 
suggested by Katis et al [12], we have rendered the distinction between safety and liveness irrelev an . 
resulting feedback-hookup introduction rule is vastly simpler, involving no calculations at all. 

Apart from the gains made in adopting the naive fixed-point view of feedback, the adoption of P red >c at e- 
transLmer semantics offers significant gains in tractability over pure relational semantics. A significant 
strength of predicate-transformer semantics is the ability to provide a clear, semantic separation be 
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assumptions and commitments. While the assumption and commitment associated with a specification state- 
ment are semantically unique, any given relational specification admits quite arbitrary assumption/commitment 
decompositions which must be treated through the introduction of adaptation rules' The availability of (dis- 
tinct) assertions and coercions also greatly adds to the power and flexibility of the refinement calculus, as 
compellingly demonstrated by our approach to the introduction and elimination of feedback assumptions. 
By introducing feedback properties as coercions we flag an intention to make the feedback property true. If 
assertions were used, it would instead indicate that we were assuming that, they were already true. Such a 
distinction could not be made in a pure relational model. 

A number of future research directions are suggested by the issues raised in this paper. The interface 
between trace- based design and sequential program code needs considerable elaboration. It would certainly 
be useful to be able to introduce more general program operators than the simple nonterminating loop 
of spec.dvnl. This might allow', for example, the clear decomposition of a program into initialisation and 
processing phases. An important future direction of this work is also to apply the refinement calculus to truly 
real-time processes. In order to do this a computation model based on continuous functions of real-time [16] 
may be adopted. However, it will require considerable development of the Isabelle real-analysis environment 
to make this feasible. Work in this direction is currently underway in collaboration with the SVRC at the 
University of Queensland. 
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